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

Figure 10.1. Some patterns that contribute to supple design

---

[ Team LiB ]

---

[ Team LiB ]
Intention-Revealing Interfaces
In domain-driven design, we want to think about meaningful domain logic. Code that produces the
effect of a rule without explicitly stating the rule forces us to think of step-by-step software
procedures. The same applies to a calculation that just results from running some code, but isn't
explicit. Without a clear connection to the model, it is difficult to understand the effect of the code
or anticipate the effect of a change. The previous chapter delved into modeling rules and
calculations explicitly. Implementing such objects requires a lot of understanding of the gritty
details of the calculation or the fine print of the rule. The beauty of objects is their ability to
encapsulate all that, so that client code is simple and can be interpreted in terms of higher-level
concepts.
But if the interface doesn't tell the client developer what he needs to know in order to use the
object effectively, he will have to dig into the internals to understand the details anyway. A reader
of the client code will have to do the same. Then most of the value of the encapsulation is lost. We
are always fighting cognitive overload: If the client developer's mind is flooded with detail about
how a component does its job, his mind isn't clear to work out the intricacies of the client design.
This is true even when the same person is playing both roles, developing and using his own code,
because even if he doesn't have to learn those details, there is a limit to how many factors he can
consider at once.
If a developer must consider the implementation of a component in order to use it, the
value of encapsulation is lost. If someone other than the original developer must infer