From Chaos to Domain Driven Design
summary
A Go side project named counter side project exposes why flat packages cause globals, cyclic dependencies and untestable business logic; author rebuilds it using CMD/pkg(internal), a group by features layout and a clean/hexagonal layering so domain code stays free of infra. Concrete tactics: entities with encapsulated increments, immutable value objects, repository interfaces with multiple implementations (in-memory, MySQL), application services for use cases, and bounded contexts plus domain events to decouple and let separate binaries or teams evolve independently.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:12LAST NEW YEAR'S EVE...
- 5:51THE SIMPLEST FLAT ARCHITECTURE
- 8:22WHAT ARE OUR GOALS?
- 10:11LAYERED ARCHITECTURE
- 12:16HEXAGONAL ARCHITECTURE
- 14:08THE GROUPED BY FEATURES ARCHITECTURE
- 17:41WHAT IS DOMAIN-DRIVEN DESIGN?
- 18:58ENTITIES
- 20:21VALUE OBJECTS
- 22:17REPOSITORIES
- 23:15SERVICES
- 23:51GROUPED BY FEATURES ARCHITECTURE DRAWBACKS
- 26:09NEXT STEPS
- 28:28THE DOMAIN-DRIVEN DESIGN ARCHITECTURE
related talks
42mFrom Chaos to Domain Driven Design in Go
49mExploring domain driven design in Go
34mWriting idiomatic Go using Domain Driven Design
29mRethinking Domain-Driven Design in Go
44mHow Do You Structure Your Go Apps?
48mDomain Driven Design: The Good Parts
45mDomain-Driven Design in Micro Frontends
47mDomain-Driven Design in Go — It Doesn't Hurt (Much)