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

domain problems that can be understood without specialized domain knowledge.
Such parts of the system seem interesting to computer scientists, and are perceived to build
transferable professional skills and provide better resume material. The specialized core, that part
of the model that really differentiates the application and makes it a business asset, typically ends
up being put together by less skilled developers who work with DBAs to create a data schema and
then code feature-by-feature without drawing on any conceptual power in the model at all.

---

Poor design or implementation of this part of the software leads to an application that never does
compelling things for the users, no matter how well the technical infrastructure works, no matter
how nice the supporting features are. This insidious problem can take root when a project lacks a
sharp picture of the overall design and the relative significance of the various parts.
One of the most successful projects I've joined initially suffered from this syndrome. The goal was
to develop a very complex syndicated loan system. Most of the strong talent was happily working
on database mapping layers and messaging interfaces while the business model was in the hands
of developers new to object technology.
The single exception, an experienced object developer working on a domain problem, devised a
way of attaching comments to any of the long-lived domain objects. These comments could be
organized so that traders could see the rationale they or others recorded for some past decision.
He also built an elegant user interface that gave intuitive access to the flexible features of the
comment model.
These features were useful and well designed. They went into production.
Unfortunately, they were peripheral. This talented developer modeled his interesting, generic way
of commenting, implemented it cleanly, and put it into users' hands. Meanwhile an incompetent
developer was turning the mission-critical "loan" module into an incomprehensible tangle that the
project very nearly did not recover from.
The planning process must drive resources to the most crucial points in the model and design. To
do that, those points must be identified and understood by everyone during planning and
development.
Those parts of the model distinctive and central to the purposes of the intended applications make
up the 
CORE DOMAIN
. The 
CORE DOMAIN
is where the most value should be added in your system.
Therefore: