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

Who Does the Work?
The most technically proficient members of project teams seldom have much knowledge of the
domain. This limits their usefulness and reinforces the tendency to assign them to supporting
components, sustaining a vicious circle in which lack of knowledge keeps them away from the work
that would build domain knowledge.
It is essential to break this cycle by assembling a team matching up a set of strong developers
who have a long-term commitment and an interest in becoming repositories of domain knowledge
with one or more domain experts who know the business deeply. Domain design is interesting,
technically challenging work when approached seriously, and developers can be found who see it
this way.
It is usually not practical to hire short-term, outside design expertise for the nuts and bolts of
creating the 
CORE DOMAIN
, because the team needs to accumulate domain knowledge, and a
temporary member is a leak in the bucket. On the other hand, an expert in a teaching/mentoring
role can be very valuable by helping the team build its domain design skills and facilitating the use
of sophisticated principles that team members probably have not mastered.
For similar reasons, it is unlikely that the 
CORE DOMAIN
can be purchased. Efforts have been made
to build industry-specific model frameworks, conspicuous examples being the semiconductor
industry consortium SEMATECH's CIM framework for semiconductor manufacturing automation,
and IBM's "San Francisco" frameworks for a wide range of businesses. Although this is a very
enticing idea, so far the results have not been compelling, except perhaps as 
PUBLISHED LANGUAGES
facilitating data interchange (see Chapter 14). The book 
Domain-Specific Application Frameworks
(Fayad and Johnson 2000) gives an overview of the state of this art. As the field advances, more
workable frameworks may be available.
Even so, there is a more fundamental reason for caution: The greatest value of custom software
comes from the total control of the 
CORE DOMAIN
. A well-designed framework may be able to
provide high-level abstractions that you can specialize for your use. It may save you from
developing the more generic parts and leave you free to concentrate on the 
CORE
. But if it
constrains you more than that, then there are three likely possibilities.
1.

---

You are losing an essential software asset. Back off restrictive frameworks in your 
CORE
DOMAIN
.
1.
The area treated by the framework is not as pivotal as you thought. Redraw the boundaries
of the 
CORE DOMAIN
to the truly distinctive part of the model.
2.
You don't have special needs in your 
CORE DOMAIN
. Consider a lower-risk solution, such as
purchasing software to integrate with your applications.
3.
One way or another, creating distinctive software comes back to a stable team accumulating
specialized knowledge and crunching it into a rich model. No shortcuts. No magic bullets.
[ Team LiB ]

---

[ Team LiB ]