Domain-Driven Design: Tackling Complexity in the Heart of Software

Customer Charge
and 
Supplier Charge
classes and defined each according to the needs of the corresponding team.
The immediate problem having been solved, they went back to doing things just as before. Oh
well.
Although we seldom think about it explicitly, the most fundamental requirement of a model is that
it be internally consistent; that its terms always have the same meaning, and that it contain no
contradictory rules. The internal consistency of a model, such that each term is unambiguous and
no rules contradict, is called 
unification
. A model is meaningless unless it is logically consistent. In
an ideal world, we would have a single model spanning the whole domain of the enterprise. This
model would be unified, without any contradictory or overlapping definitions of terms. Every logical
statement about the domain would be consistent.
But the world of large systems development is not the ideal world. To maintain that level of
unification in an entire enterprise system is more trouble than it is worth. It is necessary to allow
multiple models to develop in different parts of the system, but we need to make careful choices
about which parts of the system will be allowed to diverge and what their relationship to each
other will be. We need ways of keeping crucial parts of the model tightly unified. None of this

---

happens by itself or through good intentions. It happens only through conscious design decisions
and institution of specific processes. 
Total unification of the domain model for a large
system will not be feasible or cost-effective.
Sometimes people fight this fact. Most people see the price that multiple models exact by limiting
integration and making communication cumbersome. On top of that, having more than one model
somehow seems inelegant. This resistance to multiple models sometimes leads to very ambitious
attempts to unify all the software in a large project under a single model. I know I've been guilty
of this kind of overreaching. But consider the risks.
Too many legacy replacements may be attempted at once.