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

Chapter Nine. Making Implicit Concepts
Explicit
Deep modeling sounds great, but how do you actually do it? A deep model has power because it
contains the central concepts and abstractions that can succinctly and flexibly express essential
knowledge of the users' activities, their problems, and their solutions. The first step is to somehow
represent the essential concepts of the domain in the model. Refinement comes later, after
successive iterations of knowledge crunching and refactoring. But this process really gets into gear
when an important concept is recognized and made explicit in the model and design.
Many transformations of domain models and the corresponding code happen when
developers recognize a concept that has been hinted at in discussion or present
implicitly in the design, and they then represent it explicitly in the model with one or
more objects or relationships.
Occasionally, this transformation of a formerly implicit concept into an explicit one is a
breakthrough that leads to a deep model. More often, though, the breakthrough comes later, after
a number of important concepts are explicit in the model; after successive refactorings have
tweaked their responsibilities repeatedly, changed their relationships with other objects, and even
changed their names a few times. Everything finally snaps into focus. But the process starts with
recognizing the implied concepts in some form, however crude.
[ Team LiB ]

---

[ Team LiB ]
Digging Out Concepts
Developers have to sensitize themselves to the hints that reveal lurking implicit concepts, and
sometimes they have to proactively search them out. Most such discoveries come from listening to
the language of the team, scrutinizing awkwardness in the design and seeming contradictions in
the statements of experts, mining the literature of the domain, and doing lots and lots of
experimentation.