Domain Driven Design is a software design methodology focused on the domain, or sphere of knowledge, of those that use it. The approach enables the development of software that is focused on the complex requirements of those that need it and doesn't waste effort on anything unneeded.  

History

Eric Evans wrote the book “Domain-Driven Design: Tackling Complexity in Software,” in 2004. Since the early 1990s, he has worked on many projects developing large business systems with objects with many different approaches and many different outcomes. The book is a synthesis of that experience. In this book he introduced some Software Design concepts that have been adapted by a lot of Software solution providers, and it has been one of the most famous approaches to this day. He also paved the way to Microservices architecture as we see it today. Eric thought that when we are developing a software, our main focus should be on business or whatever activity we are trying to assist.

Topology

When thinking of an application from a technical perspective, we may break it down to several layers.

From a DDD point, this should encapsulate not all but part of the domain logic. The domain must be broken down into several sub-domains. The mentioned topology then in practice can be considered and implemented as a single service that models a sub-domain, and every service should follow this topology, or any other topology that is designed in top-down approach to integrate into one single application.

Our main domain however is more universal. It is our business scope. A domain encapsulates more than one sub-domain.

When designing a domain, we do so using a set of tools. There are mainly two types of tools that we can use. The Strategic Design tools, and the Tactical Design tools. This segregation helps breakdown our architecture to two concerns; the business, and the technology. Each sub-domain can now be bound to its own context, which is a very important concept in DDD.

‍

‍

‍

‍‍We discuss what each term means in the upcoming sections.

Strategic Design

Domain driven design is business focused, which means it is a good approach when designing software for businesses with complicated logic. It has been widely used in big enterprise solutions like government and banking sectors.  

Domain Model

The Domain is the problem. The Domain Model is the solution. A Domain Model encapsulates several Bounded Contexts. It should define a Context Map, and a Ubiquitous Language; A ubiquitous language is a vocabulary shared by everyone involved in a project, from domain experts to stakeholders, to project managers, to developers.

Bounded Contexts

The first thing you should do when implementing strategic design is to think in terms of contexts. Context is everything. The same word can have a completely different meaning if you change the context. Context helps you distinguish what do you care about.

For example, a company has three main departments, a sales department, an accounting department, and a support department.

The sales department cares about the customers’ social interests, likes and dislikes, skills, etc.

The Accounting department cares about how much money did the customer pay per year.

The support department cares about the tickets the customer opened, and bugs reported.

Depending on the context you are working with, the same word can mean completely three different things, and hence three different representations.

In Domain Driven Design, every sub-domain is bound to its own context, hence the term Bounded Context.

A Domain Model to Bounded Contexts is what classes are to objects. All Bounded contexts have the same Model but different Databases, APIs, and User Manual. Bounded contexts have relationships. Defining these relationships produces a context map.

Context Maps

Context maps are simply diagrams where you draw the relationships between bounded contexts.

Some types of relationships are

‍

You can read here more about relationships between Bounded contexts and context maps.

Strategic Design summary

First, we focus on our domain and divide it into several subdomains, each with its own complexity and functionality. The most important thing in a subdomain is for it to serve a context that it can be bounded to. It should model a single entity or more specifically an Aggregate. It should have its own Database, APIs, and User Manuals. It must share a ubiquitous language with other Bounded contexts.

We finally draw the relations between BCs and we now have a context map. This should be a good illustration of our domain.

‍