Domain-Driven Decomposition Program Playbook
Decompose a system along true business domains using DDD and event storming. Align teams to bounded contexts, extract them with anti-corruption layers, and integrate via domain events and sagas.
Decomposition fails when service boundaries are drawn around technical layers instead of business domains. This program uses domain-driven design and event storming to find true bounded contexts, aligns teams to them, and extracts services along those seams with event-driven integration.
Phase-by-Phase
Event Storming and Context Mapping. Gather domain experts and engineers to map business events, commands, and aggregates. From the storm, identify bounded contexts and their relationships, and capture a ubiquitous language glossary that the code will adopt.
Team and Boundary Alignment. Align teams to contexts following Team Topologies, define clear service ownership, and agree integration contracts between contexts. Conway's Law works for you when team and context boundaries match.
Context Extraction. Extract each bounded context into its own service, protected by anti-corruption layers and backed by its own data store. Hexagonal architecture keeps domain logic independent of infrastructure.
Event-Driven Integration. Implement domain events for cross-context communication, use sagas for workflows that span contexts, and apply CQRS where read and write models diverge. Make eventual consistency explicit and tested rather than accidental.
Team and Roles
An architect facilitates event storming and owns the context map. Backend engineers extract contexts; a data engineer leads store splits and event schemas. DevOps runs the eventing platform. Product supplies domain expertise and prioritization.
Risks and Mitigations
Wrong boundaries are the costliest mistake; event storming with real domain experts reduces the risk, and contexts can be merged before extraction if seams prove wrong. Eventual-consistency complexity is managed with sagas and explicit consistency tests. Align teams early to keep coordination clean, and resist extracting contexts that deliver no business value.
Success Criteria
Success is high team autonomy, strong domain cohesion within services, improved deployment frequency, and shorter lead time for changes.
Tooling
Use Spring Boot or an equivalent for context services, Kafka with CloudEvents for domain events, PostgreSQL for per-context stores, and Kubernetes for orchestration.