DDD in Go: designing when the language doesn't enforce the rules

Introduction

When a team decides to adopt Domain-Driven Design (DDD), they usually expect clearer domain models, better-encoded rules, and explicit invariants inside the code. In languages like Java, many of those guarantees are enforced by the language itself: constructors, strict visibility, classes, and inheritance.

Go is different. When we tried to implement Value Objects while preserving their invariants and immutability, we discovered something important: the language does not automatically protect you. The question stops being How do I implement this? and becomes How do I ensure the team follows the rules when the language doesn’t enforce them?

The real problem wasn't the Value Object

We tried the obvious approaches:

• Make the type public.
• Force creation through a factory.
• Make the type private.
• Introduce interfaces.
• Rely on linters.

Each option solved something, but broke something else:

• Public types allowed invalid constructions outside the factory.
• Private types hindered external reuse.
• Interfaces introduced semantic ambiguity.
• Linters depended on tools that are not always mature.

In theory we were modeling a simple username. In practice we were defining how we wanted the team to work. That’s when we realized the issue wasn’t purely technical: it was governance.

When the language doesn’t impose rules, the team must

Go is minimalist by design.

• It has no mandatory constructors.
• It lacks language-level mechanisms to force invariants.
• It doesn’t prevent direct instantiation of a visible type.

This means:

• Domain rules aren’t guaranteed by syntax alone.
• Team discipline becomes part of the architecture.
• Decisions must be documented and aligned across the team.

Put another way: in Go, architecture doesn’t stop at code. It extends into team agreements, PR reviews, and supporting tools.

Design also means accepting trade-offs

After evaluating multiple alternatives, we chose a pragmatic path:

• Keep Value Objects public.
• Require the use of factories.
• Allow tests to create instances directly when necessary.
• Rely on team agreements and technical review to enforce behavior.

It’s not perfect, but it’s coherent with our context and coherence matters in engineering. DDD isn’t about academic purity; it’s about clarity in the domain. If an “ideal” implementation complicates the team unnecessarily, it’s probably the wrong choice.

Recommendations

• Don’t copy patterns from other languages without questioning them.
• Define explicit team policies for how Value Objects and invariants should be handled.
• Evaluate the complexity cost of any enforcement mechanism.
• Accept that there is no universally ideal implementation.
• Document the rationale behind your decisions so future reviewers understand the trade-offs.

Conclusion

Implementing Value Objects in Go reminded us of a fundamental truth: architecture depends not only on the language, but on how the team chooses to use it. When the language doesn’t impose rules, design becomes a conscious act and technical discipline becomes an active element of the architecture. Go × DDD isn’t a problematic pairing; it’s a pairing that demands judgment. In engineering, judgment the ability to decide when to apply a rule and when not to is often more valuable than any single pattern.