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

Asset
object on each instantiation of the
objects (each time the batch was run). Instead, they let the 
Asset
object look up the two relevant
rules through their 
SINGLETON
access and pass them the appropriate 
Account
. It seemed to make
the code much more direct and so they made a pragmatic decision.
They both felt that conceptually it would have been better to associate 
Posting Rules
only with
Accounts
, while keeping the 
Asset 
focused on its job of generating 
Accruals
. They hoped that
subsequent refactorings and deeper insight would bring them back to this and show them a way to
make this clean division without losing the obviousness of the code.
[ Team LiB ]

---

[ Team LiB ]
Analysis Patterns Are Knowledge to Draw On
When you are lucky enough to have an analysis pattern, it hardly ever is the answer to your
particular needs. Yet it offers valuable leads in your investigation, and it provides cleanly
abstracted vocabulary. It should also give you guidance about implementation consequences that
will save you pain down the road.
All this feeds into the dynamo of knowledge crunching and refactoring toward deeper insight and
stimulates development. The result often resembles the form documented in the analysis pattern,
but adapted to circumstances. Sometimes the result doesn't even obviously relate to the analysis
pattern itself, yet was stimulated by the insights from the pattern.
There is one kind of change you should avoid. When you use a term from a well-known analysis
pattern, take care to keep the basic concept it designates intact, however much the superficial
form might change. There are two reasons for this. First, the pattern may embed understanding
that will help you avoid problems. Second, and more important, your 
UBIQUITOUS LANGUAGE
is
enhanced when it includes terms that are widely understood or at least well explained. If your
model definitions change through the natural evolution of the model, take the trouble to change
the names too.
Quite a lot of object models have been written about, some specialized for one kind of application
in one industry and some quite general. Most of them provide the seed of an idea, but only a few
have captured the reasoning behind the choices and the consequences that follow, which are the
most useful parts of an analysis pattern. More of these refined analysis patterns would be
valuable, to help save us from reinventing the wheel again and again. I'd be surprised ever to see
a comprehensive catalog, but industry-specific catalogs might arise. And patterns for some
domains that cross many applications could be widely shared.
This kind of reapplication of organized knowledge is completely different from attempts to reuse
code through frameworks or components, except that either could provide the seed of an idea that
is not obvious. A model, even a generalized framework, is a complete working whole, while an
analysis is a kit of model fragments. Analysis patterns focus on the most critical and difficult
decisions and illuminate alternatives and choices. They anticipate downstream consequences that
are expensive if you have to discover them for yourself.
[ Team LiB ]

---

[ Team LiB ]