Domain Driven Design (DDD): Core concepts and Enterprise Architecture

If you are building or designing APIs, Microservices or integrating systems then Domain Driven Design (DDD) offers a valuable design technique for mapping business domains to build software services of value

Using DDD is incredibly useful when designing services because it helps you rationalise the granularity of your software, the ownership boundaries and model interactions need to build de-coupled and reactive distributed systems

In this post, we review some of the core DDD concepts and apply them to business software architecture. We look at what is DDD and how to apply it when designing new or simplifying existing software services (APIs, Microservices, Events) and integrations

Domains

The domain in DDD stands for the business domain we are modelling our software for. This can be a “core” domain, a “generic” domain or a “supporting” domain. Core domains are where we want to excel as a business and our specific skills here really differentiate us from the rest of the market. Supporting domains are key to us providing value in the core domain and generic domains are areas where there is expertise in the market which we can leverage

Bounded Context

If domains are where you have expertise and skills, then think of the context in which you apply them to solve a business problem. This specific context is where you and your business do something for your customers by brining the skills into play. You use specific language to describe the service you provide and how you provide them. This is the “bounded context” in DDD

Architecture options

Given the business contexts and the functionality we want, we could go with one or more options for designing our software. Software architecture is then a decision making option based on constrains over these choices

Let us now explore some our choices before we see where DDD fits into all this

Single system architecture

Pros: Single managed software system

Cons: Complex software to handle multiple contexts, often businesses resort to off-the-shelf software to do this instead of DIY. This leads to vendor lock-in, higher OPEX costs, lack of market differentiation etc.

Distributed systems, monolithic database

Pros: Single source of truth with distributed systems and sub-systems. Low integration requirement as they are centrally integrated via database

Cons: Complex model in software leading to higher time-to-market over time. Low isolation and encapsulation of data leading to data-corruption issues or friction in changing core elements. Over time the tendency to push logic to experience layer as the core is too hard to change, this leads to fragmented rules

Distributed systems with tight integrations

Pros: If you have a set of home grown services or off-the-shelf enterprise software (ERP, CRM, Portal , Core Banking or Insurance etc) and an integrated business model (vs silos) then you want exchange of data between systems

System Integration is then key to data ownership in core systems of record and shuffling copies across the wire when another system needs this. Traditionally we use Enterprise Application Integration (EAI) with web services and messaging to let the systems interact in real-time, batch or asynchronous modes. This is familiar to most integration engineers

Cons: The use of integration patterns in EAI or system or layer oriented service design (SOA) is fantastic for a point-in-time integration objective when implemented well, however over time it can turn into spaghetti integration

The symptoms of your beautiful integrations turning to an interweb of complexity is apparant in a few key observations

1. Growing data issues over time

2. Growing lead time – i.e time from a requirement to build or change integrations to going live because of hidden coupling

3. Chatty interfaces between one or more systems leading to a fragile sequence of communication

Over time poorly integrated systems begin to look like one giant interconnected entity that requires special knowledge and team members with deep internal logic know/how to maintain … this feels just like the System Monolith, except its distributed now

Distributed systems with Domain Services

The paradigm shift that DDD brings is that you think about modelling your distributed software along the bounded contexts leading to better isolation and encapsulation. Combined with the recognition from context-mapping pattern that “self-service” is key to autonomy, teams can start to use DDD to design services that have the right level of collaboration and truely de-coupled interactions via Business Events and API market place etc

We use strategic Domain Driven Design to construct the right boundaries from our business contexts using techniques such as event-storming or domain-storytelling. This process then leads to a context map which shows the relationship between bounded contexts thus allowing us to model socio-technical interactions better

Once we have the bounded contexts, we can begin to express the model and capture transaction boundaries in interactions to build a view of “domain aggregates”. This is tactical DDD and it allows to reason about what we master vs what we hold as a value or reference leading to better distributed software design

Summary

In summary, we looked at core DDD concepts and software architecture patterns applied to business software. When there are multiple contexts, we learned that it gets complex really quickly if we have one large software system or database or even distributed systems and tight integrations between them!

DDD offers an approach to modelling software based on bounded contexts and provides strategic and tactical design techniques for building autonomous software capabilities as services