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

BOUNDED CONTEXTS
 limit
integration. A 
SHARED KERNEL
 is not feasible for teams that do not work closely together.
Duplication and fragmentation raise costs of development and installation, and
interoperability becomes very difficult.
Some successful projects break down their design into components, each with responsibility for
certain categories of functions. Usually all the components plug into a central hub, which supports
any protocols they need and knows how to talk to the interfaces they provide. Other patterns of
connecting components are also possible. The design of these interfaces and the hub that connects
them must be coordinated, while more independence is possible designing the interiors.
Several widely used technical frameworks support this pattern, but that is a secondary issue. A
technical framework is needed only if it solves some essential technical problem such as
distribution, or sharing a component among different applications. The basic pattern is a
conceptual organization of responsibilities. It can easily be applied within a single Java program.
Therefore:
Distill an 
ABSTRACT CORE
 of interfaces and interactions and create a framework that
allows diverse implementations of those interfaces to be freely substituted. Likewise,
allow any application to use those components, so long as it operates strictly through
the interfaces of the 
ABSTRACT CORE
.
High-level abstractions are identified and shared across the breadth of the system; specialization
occurs in 
MODULES
. The central hub of the application is an 
ABSTRACT CORE
within a 
SHARED KERNEL
.
But multiple 
BOUNDED CONTEXTS
can lie behind the encapsulated component interfaces, so that this
structure can be especially convenient when many components are coming from many different
sources, or when components are encapsulating preexisting software for integration.
This is not to say that components must have divergent models. Multiple components can be
developed within a single 
CONTEXT
if the teams 
CONTINUOUSLY INTEGRATE
, or they can define
another 
SHARED KERNEL
held in common by a closely related set of components. All these strategies
can coexist easily within a large-scale structure of 
PLUGGABLE COMPONENTS
. Another option, in some
cases, is to use a 
PUBLISHED LANGUAGE
for the plug-in interface of the hub.
There are a few downsides to a 
PLUGGABLE COMPONENT FRAMEWORK
. One is that this is a very
difficult pattern to apply. It requires precision in the design of the interfaces and a deep enough
model to capture the necessary behavior in the 
ABSTRACT CORE
. Another major downside is that
applications have limited options. If an application needs a very different approach to the 
CORE
DOMAIN
, the structure will get in the way. Developers can specialize the model, but they can't
change the 
ABSTRACT CORE
without changing the protocol of all the diverse components. As a
result, the process of continuous refinement of the 
CORE
, refactoring toward deeper insight, is
more or less frozen in its tracks.

---

Fayad and Johnson (2000) give a good look at ambitious attempts at 
PLUGGABLE COMPONENT
FRAMEWORKS
in several domains, including a discussion of SEMATECH CIM. The success of such
frameworks is a mixed story. Probably the biggest obstacle is the maturity of understanding
needed to design a useful framework. A 
PLUGGABLE COMPONENT FRAMEWORK
should not be the first
large-scale structure applied on a project, nor the second. The most successful examples have
followed after the full development of multiple specialized applications.