Domain-driven design (DDD) — The strategic design
Domain-Driven Design is an approach to designing systems. Nowadays, more and more people are interested and want to deep dive into this approach and by digesting several definitions originally suggested by Eric Evans back to 2003, in the “blue book”, Domain-Driven Design: Tackling Complexity in the Heart of Software, published in 2003. Also ten (10) years later, the “red book” Implementing Domain-Driven Design, by Vaughn Vernon, was published. The two books got risen in popularity in the industry and would enforce the craftsmanship movement as they brought an interesting complement to the BDD and TDD that already gained some growth in coding practices. Later Alberto Brandolini created the workshop-based method called event storming that allows teams to put into practices the DDD approach.
By the time the “blue book” was written, IT departments were separated from “the Business”. A decade later, teams were more adopting agility, at least tried to. Today teams are organised differently compared to two decades ago. They are more cross-functional product teams, and sometimes multi-disciplinary, operate with “build and run” in mind. By reading the book, some concepts may do not have a clear definition, because the industry has evolved. Everyone might have his own interpretation of Domain, Subdomain, Problem Space and Solution space. In this article, we are going walk through the foundation and key concepts of DDD, that are suggested by the “blue” and “red” books.
The DDD approach proposes a toolbox that is split in 2 parts :
- Strategic design
- Tactical design
The two (2) parts are composed of core concepts and building blocks :
- Core concepts of strategic design : domain, bounded context, context mapping, ubiquitous language and domain model
- Building blocks of the tactical design : aggregates, value object, entity, repository, service, factory and layered architecture