Notes and Quotes from Domain Driven Design by Eric EvansThese notes are a work in progress. So far I've finished about 5 chapters, or roughly 20%, of this book.Part 1 A model is a consciously structured form of knowledge yet a domain model is not a particular diagram. Domain modeling can be likened to moviemaking. Even documentary films are edited to present experiences in an idiosyncratic way to tell a story or make a point.
In DDD there are three basic uses of the model.
1) The model and the heart of the design shape each other. This is where DDD stands out from the traditional view of modeling. The model is forever bound to the implementation in order to ensure relevance and truly help maintenance.
2) The model is the backbone of team language. Communication can occur betweeen domain experts and development without translation.
3) The model is distilled knowledge. It represents the team's agreed-upon way of structuring the knowledge and distinguishing elements of interest.
When the domain is complex developers must "steep" themselves in the business knowledge. This is where a key challenge resides as technical people enjoy quantifiable problems that exercise their technical skills. Domain modeling is not typically such an exercise. It requires complicated new knowledge that does not directly contribute to a computer scientist's capabilities. Instead of breaking out of the technical comfort zone, typically the development team veers into elaborate framework design trying to solve domain problems with technology.
When a technical team focuses on the precise execution of it's own specialty it risks losing site of the bigger picture. John Cleese gave an example of this idea when he recounted the experience of a film director that cut a funny scene and replaced it with one that wasn't funny because someone walked in shot for a split-second. The director was so concerned with precise execution of his specialty he failed to realize he just made the comedy a bit less comical. Interestingly, later on the funny scene was restored by a different director that understood comedy.
There are systematic ways of thinking that developers can use to search for insight and produce effective models.
Chapter 1Ingredients of Effective Modeling
- Binding the model and the implementation, maintaining through iterations.
- Cultivating a language based on the model
- Developing a knowledge rich model - that is one with behavior and rules not just a data scheme
- Distilling the model - what is not in the model is equally as important as what is in the model
- Brainstorming and experimenting - common language with sketches and a brainstorming attitude are used… the ear can quickly detect clarity and ease or awkwardness of spoken expressions.
Creative brainstorming with experimentation using a common language, disciplined by the feedback loop of a bound implementation produces a knowledge-rich model. This is
knowledge crunching.
Chapter 2Chapter 3Chapter 4Chapter 5
