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

Chapter Five. A Model Expressed in Software To compromise in implementation without losing the punch of a MODEL-DRIVEN DESIGN requires a reframing of the basics. Connecting model and implementation has to be done at the detail level. This chapte...

Associations The interaction between modeling and implementation is particularly tricky with the associations between objects. For every traversable association in the model, there is a mechanism in the software with the same properties. A mode...

Entities (a.k.a. Reference Objects) Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity. A landlady sued me, claiming major damages to her property. The papers I was served desc...

Value Objects Many objects have no conceptual identity. These objects describe some characteristic of a thing. When a child is drawing, he cares about the color of the marker he chooses, and he may care about the sharpness of the tip. But ...

Services Sometimes, it just isn't a thing. In some cases, the clearest and most pragmatic design includes operations that do not conceptually belong to any object. Rather than force the issue, we can follow the natural contours of the problem ...

Modules (a.k.a. Packages) MODULES are an old, established design element. There are technical considerations, but cognitive overload is the primary motivation for modularity. MODULES give people two views of the model: They can look at detail wit...

Modeling Paradigms MODEL-DRIVEN DESIGN calls for an implementation technology in tune with the particular modeling paradigm being applied. Many such paradigms have been experimented with, but only a few have been widely used in practice. At prese...