Wikipedia defines domain-driven design (DDD) as “an approach to develop software for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following:
* Placing the project’s primary focus on the core domain and domain logic.
* Basing complex designs on a model of the domain.
* Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
This book is not an introduction to the DDD world, but a very detailed (close to 600 pages) technical approach about what it takes to successfully implement DDD in a company. The book is well structured. Each chapter starts with a roadmap and ends with a wrap-up. The content is a balanced mix of concept, discussion about the original DDD material by Eric Evans and examples, including some code listing that show how you implement the concepts in the software.
I will recommend this book to every software architect and software developer concerned with the architecture and long term evolution of the applications that they develop.
Reference: Implementing Domain-Driven Design, Vaughn Vernon, Addison-Wesley, 583 pages, IBSN 978-0-321-83457-7
Associated Web Site: https://vaughnvernon.co/
We strive to produce quality in the software we develop. We achieve some quality by using tests to help us avoid delivering software with a fatal number of bugs. Yet, even if we could produce completely bug-free software, that in itself does not necessarily mean that a quality software model is designed. The software model – the way the software expresses the solution to the business goal being sought – could still suffer greatly. Delivering software with few defects is obviously good. Still, we can reach higher for a well-designed software model that explicitly reflects the intended business objective, and our work may even reach the level of great.
One of the worst disconnects of a business software development effort is seen in the gap between domain experts and software developers. Generally speaking, true domain experts are focused on delivering business value. On the other hand, software developers are typically drawn to technology and technical solutions to business problems. It’s not that software developers have wrong motivations; it’s just what tends to grab their attention. Even when software developers engage with domain experts, the collaboration is largely at a surface level, and the software that gets developed often results in a translation/ mapping between how the business thinks and operates and how the software developer interprets that. The resulting software generally does not reflect a recognizable realization of the mental model of the domain experts, or perhaps it does so only partially. Over time this disconnect becomes costly. The translation of domain knowledge into software is lost as developers transition to other projects or leave the company.
As you implement DDD, you will encounter challenges. So has everyone else who has succeeded at it. What are the common challenges and how do we justify using DDD as we face them? I will discuss the more common ones:
* Allowing for the time and effort required to create a Ubiquitous Language
* Involving domain experts at the outset and continuously with the project
* Changing the way developers think about solutions in their domain