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

Option 2: A Published Design or Model
Advantages
More mature than a homegrown model and reflects many people's insights
Instant, high-quality documentation
Disadvantage
May not quite fit your needs or may be overengineered for your needs
Tom Lehrer (the comedic songwriter from the 1950s and 1960s) said the secret to success in
mathematics was, "Plagiarize! Plagiarize. Let no one's work evade your eyes. . . . Only be sure
always to call it please, 
research
." Good advice in domain modeling, and especially when attacking
a 
GENERIC SUBDOMAIN
.
This works best when there is a widely distributed model, such as the ones in 
Analysis Patterns
(Fowler 1996). (See Chapter 11.)
When the field already has a highly formalized and rigorous model, use it. Accounting and physics

---

are two examples that come to mind. Not only are these very robust and streamlined, but they are
widely understood by people everywhere, reducing your present and future training burden. (See
Chapter 10, on using established formalisms.)
Don't feel compelled to implement all aspects of a published model, if you can identify a simplified
subset that is self-consistent and satisfies your needs. But in cases where there is a well-traveled
and well-documented—or better yet, formalized—model available, it makes no sense to reinvent
the wheel.
Option 3: An Outsourced Implementation
Advantages
Keeps core team free to work on the 
CORE DOMAIN
, where most knowledge is needed and
accumulated.
Allows more development to be done without permanently enlarging the team, but without
dissipating knowledge of the 
CORE DOMAIN.
Forces an interface-oriented design, and helps keep the subdomain generic, because the
specification is being passed outside.
Disadvantages
Still requires time from the core team, because the interface, coding standards, and any
other important aspects need to be communicated.
Incurs significant overhead of transferring ownership back inside, because code has to be
understood. (Still, overhead is less than for specialized subdomains, because a generic model
presumably requires no special background to understand.)
Code quality can vary. This could be good or bad, depending on the relative caliber of the two
teams.
Automated tests can play an important role in outsourcing. The implementers should be required
to provide unit tests for the code they deliver. A really powerful approach—one that helps ensure a
degree of quality, clarifies the spec, and smooths reintegration—is to specify or even write
automated acceptance tests for the outsourced components. Also, "outsourced implementation"
can be an excellent combination with "published design or model."