Architecture
DDD
Domain-Driven Design models software around the business domain using a shared ubiquitous language, bounded contexts, aggregates and entities — aligning the code with how experts actually think. It tames genuinely complex domains and helps draw service boundaries. It is heavy for simple CRUD apps, where the ceremony outweighs the benefit.
Purpose
Domain-Driven Design builds software around the business domain itself: developers and domain experts share one ubiquitous language, and the code's names and boundaries mirror how the business actually thinks. Its core insight is that most software complexity is domain complexity, so the model deserves the design effort.
When to Use It
Genuinely complex domains — insurance, logistics, trading, healthcare — where misunderstanding the rules is the main project risk. Its bounded contexts (explicit boundaries where a term means one precise thing) are also the best available guide for drawing microservice boundaries.
Trade-offs
For simple CRUD applications the ceremony — aggregates, repositories, value objects — outweighs the benefit. The costly failure mode is adopting DDD's tactical patterns without doing the strategic work (language, boundaries), which yields complexity with no clarity.
Implementation
Start strategically: map the domain with the experts, name the bounded contexts, and make terms unambiguous within each. Tactically, model aggregates — clusters of objects changed together through one root that enforces invariants — and keep domain logic in the domain layer, not smeared across controllers and queries.