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

Executable Bedrock

---

Now let's examine the choice of the XP community and some others, to rely almost exclusively on
the executable code and its tests. Much of this book discusses ways to make the code convey
meaning through a 
MODEL-DRIVEN DESIGN
(see Chapter 3). Well-written code can be very
communicative, but the message it communicates is not guaranteed to be accurate. Oh, the
reality of the 
behavior
caused by a section of code is inescapable. But a method name can be
ambiguous, misleading, or out of date compared to the internals of the method. The assertions in
a test are rigorous, but the story told by variable names and the organization of the code is not.
Good programming style keeps this connection as direct as possible, but it is still an exercise in
self-discipline. It takes fastidiousness to write code that doesn't just 
do
the right thing but also
says
the right thing.
Elimination of those discrepancies is a major selling point of approaches such as declarative design
(discussed in Chapter 10), in which a statement of the purpose of a program element determines
its actual behavior in the program. The drive to generate programs from UML is partly motivated
by this, though it generally hasn't worked out well so far.
Still, while even code can mislead, it is closer to the ground than other documents. Aligning the
behavior, intent, and message of code using current standard technology requires discipline and a
certain way of thinking about design (discussed at length in Part III). To communicate effectively,
the code must be based on the same language used to write the requirements—the same
language that the developers speak with each other and with domain experts.
[ Team LiB ]

---

[ Team LiB ]