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

The Flagged C
ORE
On my first day on a project at a major insurance company, I was given a copy of the "domain
model," a two-hundred-page document, purchased at great expense from an industry consortium.
I spent a few days wading through a jumble of class diagrams covering everything from the
detailed composition of insurance policies to extremely abstract models of relationships between
people. The quality of the factoring of these models ranged from high-school project to rather
good (a few even described business rules, at least in the accompanying text). But where to start?
Two hundred pages.
The project culture heavily favored abstract framework building, and my predecessors had focused
on a very abstract model of the relationship of people with each other, with things, and with
activities or agreements. It was actually a nice analysis of these relationships, and their
experiments with the model had the quality of an academic research project. But it wasn't getting
us anywhere near an insurance application.
My first instinct was to start slashing, finding a small 
CORE DOMAIN
to fall back on, then refactoring
that and reintroducing other complexities as we went. But the management was alarmed by this
attitude. The document was invested with great authority. Its production had involved experts
from across the industry, and in any event they had paid the consortium far more than they were
paying me, so they were unlikely to weigh my recommendations for radical change too heavily.
But I knew we had to get a shared picture of our 
CORE DOMAIN
and get everyone's efforts focused
on that.
Instead of refactoring, I went through the document and, with the help of a business analyst who
knew a great deal about the insurance industry in general and the requirements of the application
we were to build in particular, I identified the handful of sections that presented the essential,
differentiating concepts we needed to work with. I provided a navigation of the model that clearly
showed the 
CORE
and its relationship to supporting features.

---

A new prototyping effort started from this perspective, and quickly yielded a simplified application
that demonstrated some of the required functionality.
Two pounds of recyclable paper was turned into a business asset by a few page tabs and some
yellow highlighter.
This technique is not specific to object diagrams on paper. A team that uses UML diagrams
extensively could use a "stereotype" to identify core elements. A team that uses the code as the
sole repository of the model might use comments, maybe structured as Java Doc, or might use
some tool in its development environment. The particular technique doesn't matter, as long as a
developer can effortlessly see what is in and what is out of the 
CORE DOMAIN
.
Therefore (as another form of 
HIGHLIGHTED CORE
):