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

Continuous Integration
Having defined a 
BOUNDED CONTEXT
, we must keep it sound.
When a number of people are working in the same 
BOUNDED CONTEXT
, there is a strong
tendency for the model to fragment. The bigger the team, the bigger the problem, but
as few as three or four people can encounter serious problems. Yet breaking down the
system into ever-smaller 
CONTEXTS
 eventually loses a valuable level of integration and
coherency.
Sometimes developers do not fully understand the intent of some object or interaction modeled by
someone else, and they change it in a way that makes it unusable for its original purpose.
Sometimes they don't realize that the concepts they are working on are already embodied in
another part of the model and they duplicate (inexactly) those concepts and behavior. Sometimes
they are aware of those other expressions but are afraid to tamper with them, for fear of
corrupting the existing functionality, and so they proceed to duplicate concepts and functionality.
It is very hard to maintain the level of communication needed to develop a unified system of any
size. We need ways of increasing communication and reducing complexity. We also need safety
nets that prevent overcautious behavior, such as developers duplicating functionality because they
are afraid they will break existing code.
It is in this environment that Extreme Programming (XP) really comes into its own. Many XP
practices are aimed at this specific problem of maintaining a coherent design that is being
constantly changed by many people. XP in its purest form is a nice fit for maintaining model
integrity within a single 
BOUNDED CONTEXT
. However, whether or not XP is being used, it is essential
to have some process of 
CONTINUOUS INTEGRATION
.
C
ONTINUOUS INTEGRATION
means that all work within the context is being merged and made
consistent frequently enough that when splinters happen they are caught and corrected quickly.
C
ONTINUOUS INTEGRATION
, like everything else in domain-driven design, operates at two levels: (1)

---

the integration of model concepts and (2) the integration of the implementation.
Concepts are integrated by constant communication among team members. The team must
cultivate a shared understanding of the ever-changing model. Many practices help, but the most
fundamental is constantly hammering out the 
UBIQUITOUS LANGUAGE
. Meanwhile, the
implementation artifacts are being integrated by a systematic merge/build/test process that
exposes model splinters early. Many processes for integration are used, but most of the effective
ones share these characteristics:
A step-by-step, reproducible merge/build technique;
Automated test suites; and
Rules that set some reasonably small upper limit on the lifetime of unintegrated changes.
The other side of the coin in effective processes, although it is seldom formally included, is
conceptual
integration.
Constant exercise of the 
UBIQUITOUS LANGUAGE
in discussions of the model and application
Most Agile projects have at least daily merges of each developer's code changes. The frequency
can be adjusted to the pace of change, as long as any unintegrated change would be merged
before a significant amount of incompatible work could be done by other team members.
In a 
MODEL-DRIVEN DESIGN
, the integration of concepts smooths the way for the integration of the
implementation, while the integration of the implementation proves the validity and consistency of
the model and exposes splinters.
Therefore: