advanced
DDD basics
Use ubiquitous language, bounded contexts, aggregates, and domain services where business complexity is high enough to justify the modeling cost.
Domain-Driven Design aligns code with business language through ubiquitous language, bounded contexts, aggregates, entities, value objects, and domain services. It pays off when rules are rich, contested, and long-lived—not for every CRUD admin screen. Strategic design (contexts, relationships) matters as much as tactical patterns.
On interviews: explain when DDD is worth the modeling cost. Walk through ubiquitous language example and context map sketch.
Common pitfalls: DDD jargon without collaboration with domain experts; aggregates too large or too small; anemic models with all logic in application services.
Checklist:
- Glossary shared with product and stakeholders.
- Bounded contexts named by business capability.
- Aggregates enforce consistency boundaries.
- Context integration patterns chosen explicitly.