Golang on Osmar Petry

Domain-Driven, Data-Oriented Design (DDDOD)

Sun, 01 Jun 2025 00:00:00 +0000

Overview

Bill Kennedy adapts Domain-Driven Design principles to Go by emphasising data flow and simplicity. DDDOD keeps the focus on reliable data transformations while preserving idiomatic Go patterns.

Why not pure DDD?

Traditional DDD can introduce excessive abstraction and ceremony in Go projects.
Too many layers and interfaces obscure intent, reducing maintainability.

Core pillars

Data-oriented design: prioritise data models and their transformations; ensure data can cross layers safely.
Validation & trust: embed validation logic early; fail fast to maintain integrity.
Structured layers: app → business → storage; each layer defines clear contracts and side-effects.
Domain isolation: separate bounded contexts to prevent accidental coupling and cascading failures.

Implementation tips

Use packages to reflect domains (internal/user, internal/auth); avoid grab-bag packages like common.
Expose only necessary APIs; keep implementation details private.
Guard entry points with validation and logging to catch anomalies early.
Leverage functional options or constructors to initialize services with dependencies explicitly.

References

Bill Kennedy, “Domain-Driven, Data-Oriented Design” talk and articles (Ardan Labs).
Ardan Labs Service repository as a starter kit: https://github.com/ardanlabs/service

[[ddd|Domain-Driven Design: Tackling Complexity in the Heart of Software]]

Gophers 2025 — Event Report

Tue, 20 May 2025 00:00:00 +0000

Introduction

Gophers 2025 brought the Go community together in Anita Garibaldi, Santa Catarina, for two full days of talks, panels, and hands-on workshops. Sessions ranged from organizational culture and dependency-injection strategies to Kubernetes tuning, automation, game development with Ebiten, and end-to-end observability. This report consolidates every note found in the Gophers 2025/ directory into a single English-language document. It follows the event chronologically and highlights technical takeaways, workshop content, a real-world case study, and concrete action items.

Go Serialization Options

Mon, 12 May 2025 00:00:00 +0000

Summary

Go types can expose custom wire formats through encoding/json and related packages. The main choices are MarshalText / UnmarshalText, MarshalJSON / UnmarshalJSON, or explicit helper functions. Each option trades off convenience, control, and complexity.

1. `MarshalText` / `UnmarshalText`

Implements encoding.TextMarshaler and encoding.TextUnmarshaler.

This converts values to plain text. JSON, XML, and other encoders automatically use it when a custom JSON marshaler is absent.

func (n Name) MarshalText() ([]byte, error) {
	return []byte(n.value), nil
}

func (n *Name) UnmarshalText(data []byte) error {
	n.value = string(data)
	return nil
}

2. `MarshalJSON` / `UnmarshalJSON`

Implements json.Marshaler and json.Unmarshaler.

Package Oriented Design

Mon, 12 May 2025 00:00:00 +0000

Summary

Bill Kennedy’s Package Oriented Design (POD) emphasises starting and ending architectural decisions at the package level. Each package should provide a focused solution for a domain problem to keep code composable, testable, and maintainable.

Definition

POD identifies where each package belongs and the design rules it follows. Packages act as the building blocks of Go applications, supporting composition and isolation.

Guiding philosophy

Purpose over storage: packages should provide behaviour, not just hold utilities.
Encapsulation: expose only necessary APIs and hide implementation details.
Portability: a consistent package structure makes discussion and reuse easier across projects.
Layering: organise code into purposeful layers, such as kit, application, and service, with explicit interaction rules.

Benefits

Modularity: domain-specific packages reduce unwanted coupling.
Maintainability: clear responsibilities make testing and refactoring easier.
Scalability: well-defined package boundaries support growth in complexity and team size.

Package responsibilities

Live in one place per domain, such as internal/user or internal/platform.
Provide a specific solution and avoid generic buckets like common or util.
Export only the API needed by consumers and keep implementation details private.
Name files to reflect behaviour so callers understand what the package delivers.

Layering cheat-sheet

`kit`

Shared libraries with zero dependency on application packages.

Golang on Osmar Petry

Domain-Driven, Data-Oriented Design (DDDOD)

Overview

Why not pure DDD?

Core pillars

Implementation tips

References

Related Notes

Gophers 2025 — Event Report

Introduction

Go Serialization Options

Summary

1. MarshalText / UnmarshalText

2. MarshalJSON / UnmarshalJSON

Package Oriented Design

Summary

Definition

Guiding philosophy

Benefits

Package responsibilities

Layering cheat-sheet

kit

1. `MarshalText` / `UnmarshalText`

2. `MarshalJSON` / `UnmarshalJSON`

`kit`