Strategic Domain-Driven Design

Strategic Domain-Driven Design is a set of principles for maintaining model integrity, distillation of the domain model and working with multiple models.

Over time legacy systems lose focus of their domain model and become complex.  This increases the cost for preventative and corrective maintenace.  A loss of focus on the domain model does not mean a rewrite of the system is required.  Will rewriting provide value?  With the principles of lean thinking, this question has to be taken into consideration.  It maybe easier to refactor legacy code where you can, but always focus on adding value.

The figure above displays the key activities for maintaining model integrity.  These focus on three key activities for maintaining model integrity.  Ensure models are held in a bounded context, are continuously integrated into implementations and tested, and are mapped into a context.

Bounded Context

Multiple models are in play on any large project yet when code based on distinct models is combined, software becomes buggy, unreliable and difficult to understand.  This helps guides you into thinking about software as a portfolio of objects.  Communication among team members become confused.  It is often unclear in what context a model should not be implied as each member may have its own ubiquitous language.  To avoid this: –

• Explicitly define the context within which a model applies.
• Explicitly set boundaries in terms of team organisation, usage within specific parts of the application and physical manifestations such as codebases and database schemas.
• Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.

Continuous Integration

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.

• Institute a process of merging all code and other implementations’ artefacts frequently, with automated tests to flag fragmentation quickly.
• Relentlessly exercise the ubiquitous language to hammer out a shared view of the model as the concepts evolve in different people’s heads.

Context Map

An individual bounded context leaves some problems in the absence of a global view.  The context of other models may still be vague.  People on other teams won’t be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections.  When connections must be made between different contexts, they tend to bleed into each other; therefore: –

• Identify each model in play on the project and define its bounded context.  This includes the implicit models of non object-orientated systems.
• Name each bounded context and make the names part of the ubiquitous language.
• Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing.
• Map the existing terrain.  Take up the transformation later.