Rethinking Domain-Driven Design in Go
summary
Claims DDD cuts accidental complexity and speeds delivery; a concrete case shows a credit-note feature that originally touches seven microservices, three teams, and takes three months, then simplifies after merging invoice-related services into one bounded context. Code techniques shown in Go include keep valid state in memory via package-level encapsulation and constructors, make the domain package database-agnostic with a repository pattern and in-memory test adapters, and mirror business terms in types and methods so rules (e.g., credit note invariants) are enforced and readable.
AI-written summary · about
chapters (9)
- 0:00Introduction to DDD
- 2:27The billing mate problem
- 3:30Failed solutions and challenges
- 5:01Analyzing the failure
- 9:26Introducing DDD techniques
- 12:28Validating state in memory
- 16:54Database agnostic domain
- 19:56Ubiquitous language in code
- 22:30DDD myths and conclusion
related talks
49mExploring domain driven design in Go
47mDomain-Driven Design in Go — It Doesn't Hurt (Much)
34mWriting idiomatic Go using Domain Driven Design
44mGo in Domain Driven Design
42mFrom Chaos to Domain Driven Design in Go
42mHigh-Speed DDD (revisited)
45mDon't Overdose on Domain-Driven Design
55mDomain-Driven Design: back to the roots