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

Integration is always expensive. Sometimes the benefit is small.
In addition to the usual expense of coordinating teams, integration forces compromises. The
simple specialized model that can satisfy a particular need must give way to the more abstract
model that can handle all situations. Perhaps some completely different technology could provide
certain features very easily, but it is difficult to integrate. Maybe some team is just so hard to get
along with that nothing works very well when other teams try to collaborate with them.
In many circumstances, integration provides no significant benefit. If two functional parts do not
call upon each other's functionality, or require interactions between objects that are touched by
both, or share data during their operations, then integration, even through a translation layer,
may not be necessary. Just because features are related in a use case does not mean they must
be integrated.
Therefore:
Declare a 
BOUNDED CONTEXT
 to have no connection to the others at all, allowing
developers to find simple, specialized solutions within this small scope.
The features can still be organized in middleware or the UI layer, but there will be no sharing of
logic, and an absolute minimum of data transfer through translation layers—preferably none.
Example
An Insurance Project Slims Down

---

One project team had set out to develop new software for insurance claims that would integrate
into one system everything a customer service agent or a claims adjuster needed. After a year of
effort, team members were stuck. A combination of analysis paralysis and a major up-front
investment in infrastructure had found them with nothing to show an increasingly impatient
management. More seriously, the scope of what they were trying to do was overwhelming them.
A new project manager forced everyone into a room for a week to form a new plan. First they
made lists of requirements and tried to estimate their difficulty and assign importance. They
ruthlessly chopped the difficult and unimportant ones. Then they started to bring order to the
remaining list. Many smart decisions were made in that room that week, but in the end, only one
turned out to be important. At some point it was recognized that 
there were some features for
which integration provided little added value.
For example, adjusters needed access to some
existing databases, and their current access was very inconvenient. 
But, although the users
needed to have this data, none of the other features of the proposed software system would use
it
.
Team members proposed various ways of providing easy access. In one case, a key report could
be exported as HTML and placed on the intranet. In another case, adjusters could be provided with
a specialized query written using a standard software package. All these functions could be
integrated by organizing links on an intranet page or by placing buttons on the user's desktop.
The team launched a set of small projects that attempted no more integration than launching from
the same menu. Several valuable capabilities were delivered almost overnight. Dropping the
baggage of these extraneous features left a distilled set of requirements that seemed for a while to
give hope for delivery of the main application.
It could have gone that way, but unfortunately the team slipped back into old habits. They
paralyzed themselves again. In the end, their only legacy turned out to be those small applications
that had gone their 
SEPARATE WAYS
.
Taking 
SEPARATE WAYS
forecloses some options. Although continuous refactoring can eventually
undo any decision, it is hard to merge models that have developed in complete isolation. If
integration turns out to be needed after all, translation layers will be necessary and may be
complex. Of course, this is something you will face anyway.
Now, turning back to more cooperative relationships, let's look at ways to scale up integration. . . .
[ Team LiB ]

---

[ Team LiB ]