Ubiquitous Language Mini-Glossary
Choose a domain (e.g., payments). Write 10 core terms, one precise definition each, and 3 ambiguous terms to avoid. Validate with a non-engineer.
Backend & Runtime / Knowledge library
Domain-Driven Design
modeling complex business domains in software
Why learn Domain-Driven Design?
Domain-Driven Design helps teams handle complex business logic by aligning software models with real business language and boundaries. It reduces misunderstandings between engineers and domain experts, improves changeability, and keeps critical rules explicit in code.
Where it came from
2003: Eric Evans publishes Domain-Driven Design (the 'Blue Book'). Mid-2000s: Strategic patterns (bounded contexts, context maps) gain wider adoption. 2009-2013: CQRS and event sourcing are often combined with DDD in complex systems. 2013: Vaughn Vernon publishes Implementing Domain-Driven Design, expanding tactical guidance. Late 2010s+: DDD becomes a common fit for backend microservice decomposition.
- 2003: Eric Evans publishes Domain-Driven Design (the 'Blue Book').
- Mid-2000s: Strategic patterns (bounded contexts, context maps) gain wider adoption.
- 2009-2013: CQRS and event sourcing are often combined with DDD in complex systems.
- 2013: Vaughn Vernon publishes Implementing Domain-Driven Design, expanding tactical guidance.
- Late 2010s+: DDD becomes a common fit for backend microservice decomposition.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Choose a domain (e.g., payments). Write 10 core terms, one precise definition each, and 3 ambiguous terms to avoid. Validate with a non-engineer.
- For an online store, split into 3-5 bounded contexts (catalog, pricing, orders, fulfillment, etc.). Add one upstream/downstream relationship and one anti-corruption layer point.
- Implement an Order aggregate with rules: cannot confirm empty order, cannot ship unless confirmed, emit domain events on confirm/ship. Add unit tests for each rule.
- Given two teams with conflicting definitions of 'Customer', propose a context map and integration strategy to prevent model leakage.
- Take a CRUD-style service and move at least 3 business rules from application service into entities/value objects while preserving test coverage.
More ways to practice
Bounded Context Split
For an online store, split into 3-5 bounded contexts (catalog, pricing, orders, fulfillment, etc.). Add one upstream/downstream relationship and one anti-corruption layer point.
Aggregate Invariants Kata
Implement an Order aggregate with rules: cannot confirm empty order, cannot ship unless confirmed, emit domain events on confirm/ship. Add unit tests for each rule.
Context Map Review
Given two teams with conflicting definitions of 'Customer', propose a context map and integration strategy to prevent model leakage.
Refactor Anemic Model
Take a CRUD-style service and move at least 3 business rules from application service into entities/value objects while preserving test coverage.
Documentation and sources
- Domain Language (DDD community) (domainlanguage.com)
- DDD Reference by Eric Evans (domainlanguage.com)
- Implementing Domain-Driven Design (Vernon) (www.oreilly.com)
- Context Mapper (tooling) (contextmapper.org)
Catalog research notes
- DDD is now commonly paired with microservices via bounded-context-aligned service boundaries.
- Remote event storming (Miro/Mural/FigJam) has become standard for distributed teams.
- DDD is frequently implemented with Hexagonal/Clean Architecture in backend systems.
- Teams increasingly use AI drafts for domain glossaries, then validate with domain experts.
Connect the ideas
Explore next
Real World Example
Autonomous Logistics Orchestration
Global freight forwarding firms managing multi-modal transport networks.
The business problem
Monolithic software architectures fail to distinguish between the distinct business rules of international customs compliance and local last-mile delivery, leading to rigid, error-prone codebases that cannot adapt to regional regulatory shifts.
How this topic solves it
Applying Domain-Driven Design (DDD) to decompose the system into Bounded Contexts, ensuring that the 'Customs' domain model remains decoupled from the 'Delivery' domain model, even when they share data entities like 'Shipment'.
- Identify core domains through event storming with domain experts to define clear boundaries.
- Establish a Ubiquitous Language that standardizes terminology across both technical and business teams.
- Define Bounded Contexts to isolate the Customs Compliance engine from the Last-Mile Dispatch logic.
- Implement an Anti-Corruption Layer (ACL) to translate data between the legacy Shipment database and the new domain-specific services.
- Refine the domain model iteratively to ensure it reflects current business rules rather than database schema constraints.
Shows how the Shipment entity is interpreted differently across two distinct business domains.
Handles tariffs and legal declarations
Handles routing and driver assignment
Shared data object
Translation service
- Shipment Entity → 1:1 (Compliance View) → Customs Context
- Shipment Entity → 1:N (Logistics View) → Delivery Context
- Delivery Context → Requests data via → Anti-Corruption Layer
- Anti-Corruption Layer → Translates to → Customs Context
Expected business outcome
Improved system maintainability and the ability to update regional compliance logic without disrupting core delivery operations.
Limitations and checks
The primary tradeoff is increased architectural complexity due to the overhead of maintaining multiple models and translation layers; this can be checked by monitoring the frequency of cross-context integration failures.