Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
Chapter 2: Communication and the use of language
More pervasively the language is used, the more smoothly understanding will flow
Persistent use of the UBIQUITOUS LANGUAGE will force the model's weaknesses into the open
Will lead to changes that will be recognized as changes in the domain model
By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas
Use model as the backbone of a language.
Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.
Modeling out loud
Play with the model as you talk about the system. Describe scenarios out loud using elements and interations of the model.
Find easier ways to say what you need to say, then take those new ideas back down to the diagrams and code.
One team, one language
Protecting domain experts from technical language: Of course there are technical components of the design that may not concern the domain experts, but the core of the model had better interest them
If sophisticated domain experts don't understand the model, there is something wrong with the model.
Multiplicity of languages is often necessary, but the linguistic division should never be between the domain experts and the developers.
Documents and diagrams
The trouble comes when people feel compelled to convey the whole model or design through UML. They are too complete because people feel they have to put all the objects that they are going to code into a modeling tool. With all that detail, no one can see the forest for the trees.
Attributes and relationships are only half the story. Behavior of those objects and the constraints on them are not so easily illustrated.
UML diagram cannot convey two fo the most important aspects of a model: the meaning of the concepts it represents and what the objects are meant to do
Careful use of language can fill this role pretty will
Diagrams are means of communication and facilitate brainstorming. They serve these ends best if they are minimal
Written design documents
Documents should complement code and speech
Dependence on the code as communication medium motivates developers to keep the code clean and transparent
Documents, comments etc get out of syc with the system
Language and white board illustrations do not persist long enough to get out of touch with the system.
A document shouldn't try to do what the code already does well. The code already supplies the detail. It is the exact specification of the program behavior.
Other documents need to illuminate meaning, to give insight to large-scale structures and to focus attention on core elements.
Documents can clarify design intent when programming language does not support a straightforward implementation of a concept
If a document isn't playing an important role, keeping it up to date through sheet will and discipline wastes effort
Chapter 1: Crunching Knowledge
Ingredients of effective modeling
Binding the model and the implementation. (Evans used a prototype to implement a model that experts could see)
Cultivating a language based on the model.
At first, domain exerts had to explain basic information, but as the project progresses, domain and technical experts began speaking and understanding the same language.
Developing a knowledge rich model.
Objects had behavior and enforce rules. Not just a data scheme
Distilling the model
Important concepts were added to the model as it became more complete
Concepts that proved not to be useful were dropped
Brainstorming and experimenting
discussions became labs for continued experimentation and refinement of the model
Success comes in an emerging set of abstract concepts that make sense of all the detail. Comes after trying many ideas
Collaborative activity between developers and domain experts
Waterfall: experts talk to analysts who abstract problems for developers to code. No feedback for analysts to improve the model
Iterative projects can still have problems if they fail to build up knowledge because they don't abstract
Developers just have experts describe the problem and they go build it. But programmers learn what the application should do and not the principles behind it.
When we set out to write software, we never know enough. Domains that seem less technically daunting can be deceiving (unknown unknowns)
Highly productive teams grow their knowledge conciously, practicing continuous learning
technical, domain-modeling and domain knowledge
Model should help newcomers learn. Discussing it should result in learning
Don't have to become a domain expert. But should be able to talk with them and sanity check the software being built
Move beyond entities and values to business activities and rules
More than just find the nounds
May be actual inconsistency among business rules.
Example: Cargo-Voyage Overbooking by 10%
Code could be hidden in guard rule for max booking
Overbooking rule could be moved into a POLICY (design pattern known as STRATEGY)
Rule is now in own class, and is clear to both technical and domain experts
As knowledge grew, model shifted from transferring items from place to place to transferring responsibility for items from party to party
Forward by Martin Fowler
Key to controlling complexity is a good domain model
provides underlying structure
Greatest value of a domain model is that is provides a UBIQUITOUS LANGAUGE that ties domain experts and technologists together
Domain models evolve over time and the best ideas often come after the initial release
Implementation should be considered in design
Development is iterative
Developers and domain experts have a close relationship
For most software projects, the primary focus should be on the domain and domain logic
Complex domain designs should be based on a model
Domain-driven design is a difficult technical challenge that can pay off big, opening opportunities just when most software projects begin to ossify into legacy.
The model and the heart of the design shape each other
The model is the backbone of a language used by all team members
Can communicate with domain experts without translation
The model is distilled knowledge
A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.
Using a model in these ways can support the development of software that would otherwise take a massive investment of ad hoc development
creating a lucid model that cuts through that complexity is exciting.
There are systematic ways of thinking that developers can employ to search for insight and produce effective models. There are design techniques that can bring order to a sprawling software application. Cultivation of these skills makes a developer much more valuable, even in an initially unfamiliar domain.
Chapter 3: Binding Model and Implementation
What good is a model on paper, unless it directly aids the development of running software?
Model Driven Design
Tightly relating the code to an underlying model gives the code meaning and makes the model relevant.
Software that lacks a concept at the foundation of its design is, at best, a mechanism that does useful things without explaining its actions.
If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect.
MODEL-DRIVEN DESIGN discards the dichotomy of analysis model and design to search out a single model that serves both purposes.
This requires us to be more demanding of the chosen model, since it must fulfill two quite different objectives.
The modeling and design process becomes a single iterative loop.
Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious.
Revisit the model and modify it to be implemented more naturally in software and gain deeper domain insight.
Model should also support a robust UBIQUITOUS LANGUAGE