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

Try, Try Again
The examples I've given don't convey the amount of trial and error involved. I might follow half a
dozen leads in conversation before finding one that seems clear and useful enough to try out in the
model. I'll end up replacing that one at least once later, as additional experience and knowledge
crunching serve up better ideas. A modeler/designer cannot afford to get attached to his own
ideas.
All these changes of direction are not just thrashing. Each change embeds deeper insight into the
model. Each refactoring leaves the design more supple, easier to change the next time, ready to
bend in the places that turn out to need to bend.
There really is no choice, anyway. Experimentation is the way to learn what works and doesn't.
Trying to avoid missteps in design will result in a lower quality result because it will be based on
less experience. And it can easily take longer than a series of quick experiments.
[ Team LiB ]

---

[ Team LiB ]
How to Model Less Obvious Kinds of Concepts
The object-oriented paradigm leads us to look for and invent certain kinds of concepts. Things,
even very abstract ones such as "accruals," are the meat of most object models, along with the
actions those things take. These are the "nouns and verbs" that introductory object-oriented
design books talk about. But other important categories of concepts can be made explicit in a
model as well.
I'll discuss three such categories that were not obvious to me when I started with objects. My
designs became sharper with each one of these I learned.
Explicit Constraints
Constraints make up a particularly important category of model concepts. They often emerge
implicitly, and expressing them explicitly can greatly improve a design.
Sometimes constraints find a natural home in an object or method. A "Bucket" object must
guarantee the invariant that it does not hold more than its capacity.