Domain-Driven Design (DDD) is an approach to software development that puts the business domain at the center of design decisions. It's particularly valuable for complex business applications.
Core Concepts#
Ubiquitous Language#
The shared vocabulary between developers and domain experts.
❌ Without ubiquitous language:
Developer: "The UserAccount entity has a status field"
Expert: "You mean the customer's membership state?"
Developer: "Sure, whatever. It's in the database."
✅ With ubiquitous language:
Developer: "When a Member's subscription expires, their MembershipStatus becomes Inactive"
Expert: "Exactly, and they lose access to premium features"
Everyone uses the same terms:
- Member (not User, Customer, or Account)
- Subscription (not Plan or Package)
- MembershipStatus (not status or state)
Bounded Contexts#
Different parts of the system can have different models for the same concept.
E-commerce system:
┌─────────────────────┐ ┌─────────────────────┐
│ Sales Context │ │ Shipping Context │
│ │ │ │
│ Customer: │ │ Customer: │
│ - name │ │ - name │
│ - email │ │ - shippingAddress │
│ - paymentMethod │ │ - deliveryPrefs │
│ - orderHistory │ │ │
└─────────────────────┘ └─────────────────────┘
Same concept (Customer), different properties for different contexts.
Building Blocks#
Entities#
Loading code block...
Value Objects#
Loading code block...
Aggregates#
Loading code block...
Domain Events#
Loading code block...
Repositories#
Loading code block...
Domain Services#
Loading code block...
Application Layer#
Loading code block...
Strategic Design#
Context Mapping#
Relationships between bounded contexts:
┌──────────────┐ ┌──────────────┐
│ Sales │─────▶│ Shipping │
│ (upstream) │ │ (downstream) │
└──────────────┘ └──────────────┘
Customer/ Conformist
Supplier
┌──────────────┐ ┌──────────────┐
│ Catalog │◀ ─ ─▶│ Search │
└──────────────┘ └──────────────┘
Shared Kernel
┌──────────────┐ ┌──────────────┐
│ Orders │─ ─ ─▶│ Legacy │
└──────────────┘ │ System │
Anti-corruption └──────────────┘
Layer
Anti-Corruption Layer#
Loading code block...
Conclusion#
DDD is about aligning software with business reality. Start with ubiquitous language and bounded contexts. Use tactical patterns (entities, value objects, aggregates) to model complex domains.
DDD adds complexity—use it where the domain is genuinely complex. For simple CRUD applications, simpler approaches work better.