Summary
Domain-Driven Design (DDD) is a software development philosophy introduced by Eric Evans that advocates for building software models that closely reflect the business domain, using a shared language between developers and domain experts.
What is DDD?
Domain-Driven Design is a collection of principles, patterns, and practices for designing complex software systems by placing the business domain at the center of all design decisions. It was introduced by Eric Evans in his 2003 book of the same name.
Core DDD concepts include the Ubiquitous Language (a shared vocabulary between developers and business stakeholders), Bounded Contexts (explicit boundaries within which a model applies), Aggregates (clusters of domain objects treated as a unit), and Domain Events (records of things that happened in the domain).
DDD is closely related to the microservices architectural style. Bounded Contexts from DDD often map directly to individual microservices, providing a principled basis for deciding where service boundaries should lie. DDD helps teams avoid the "big ball of mud" problem by structuring complexity into manageable, coherent domain models.
Why is DDD relevant?
- Business alignment: DDD ensures that software models accurately reflect business concepts, reducing the translation gap between requirements and code
- Service boundaries: Bounded Contexts provide a principled approach to decomposing a system into microservices
- Managing complexity: Strategic and tactical DDD patterns help teams navigate the inherent complexity of large-scale software systems