Domain-driven design (DDD) is an approach to software development 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.
I’m reading Eric Evans’ tome and here are some of my notes and thoughts through chapter one…
In DDD, three basic uses determine the choice of a model:
- The model and the heart of the design shape each other
- The model is the backbone of a language used by all the team members
- The model is distilled knowledge
A good reminder from the intro of the book:
The heart of software is the ability to solve a domain-related problem.
Chapter 1: Crunching Knowledge
Ingredients of effective modeling:
- Binding the model and the implementation – Evans goes into detail about the importance of binding the model and the implementation. So often (I’ve already experienced this first hand in my few years in the industry), we spend a lot of time distilling concepts and documenting things and then developing an instantaneous amnesia as we get into implementation. The model needs to serve the implementation throughout the project.
- Cultivating a language based on the model – This concept is actually what sparked my interest in DDD. I’ve done a lot of work in the last year on a design and style library, as well as the implementation of it in client-facing projects. I’ve had so many conversations about elements on the page where we interchangeably use six or seven different terms for the same thing. Developing a vocabulary up front is so vital.
- Developing a knowledge rich model – I think the book will dive deeper into this one, but so far, my interpretation is that building a model requires more than a superficial once-over of the resources and actions. It requires serious collaboration between domain experts and developers, finding the nuances and questions assumptions to get deeper to into the core of the problem.
- Distilling the model – What do you do when you have all the information in the model? Well, then you go through it again and you figure out what the core concepts are, what patterns are reused and what pieces you can take out.
- Brainstorming and experimenting – The final ingredient is collaborative iteration! Honestly, this applies to everything in software and life.
And, a few good quotes that stuck out from what I’ve read so far…
In waterfall, you rely on Business Analysts to distill the model. In DDD, you practice collaborative model crunching.
Domain experts are usually not aware of how complex their mental processes are, as in the course of their work, they navigate all these rules, reconcile contradictions, and fill in the gaps with common sense. Software can’t do this. It is through knowledge crunching and close collaboration with software experts that the rules are clarified, fleshed out, reconciled, or placed out of scope.
I’ll keep adding notes and adding links from this post as I progress through the book.