10 Crucial Points on DDD Every Software Architect Must Know

Point #1 – Understand Core Domains Well

Generally, businesses solve problems in a particular domain—for example, the banking, insurance, education, entertainment and healthcare domains. Businesses may come up with a software program as solution to a problem that exists in the domain. Users use the software program to perform some tasks in that particular domain. For example, users use a banking software to perform some tasks in the banking domain.

Generally, domain is complex. You need to logically divide the domain into subdomains. Subdomain is a clear area of expertise and a segment of the domain. There are three types of subdomains: core, generic and supporting.

Focus on the core subdomains (aka core domains). For example, in the banking domain, cards and accounts are examples of core subdomains. Generally, organizations invest hugely in the core domains to develop software.

Point #2 – Keep your domain model simple and accurate

A problem domain may have so many things – the volume of information may be enormous. We don’t need all the information and or knowledge about the domain to develop software. Here comes the domain model. A domain model is a simplified and very organized form of knowledge. It doesn’t capture anything that is unessential. A domain model captures only those things that fulfill the purpose.

Point #3 – Bounded Contexts Cover Necessary Aspects of the Subdomains

Ideally, one subdomain should be mapped to one bounded context in the solution space. The bounded context doesn’t need to consider every aspect of the subdomain. It will focus on only those aspects that are essential for the solution. For example, Human Heart is your target subdomain. Here we will think about one bounded context that will implement a domain model focusing on upper heart chambers, lower heart chambers, and redirecting electrical signals from upper heart chamber along a controlled path to the lower heart chambers.

We may have multiple bounded contexts (BCs) within one subdomain. But in this, we must have solid justification for having multiple BCs within a subdomain. For example, we need to think about another bounded context within the heart subdomain to implement the model focusing on artery, heart wall and a graft to repair a balloon-like bulge in the artery or wall of the heart muscle.

Sometimes, one single bounded context may span multiple subdomains. But it is better to avoid this kind of conflated BC. For example, we need to think about a bounded context spanning Lung Subdomain and Heart Subdomain to implement the model focusing on combined heart surgery and lung tumor resection.

Point #4 – One Ubiquitous Language per Bounded Context.

There is one Ubiquitous Language per Bounded Context.

Point #5 – A Domain Model Is Implemented Within A Bounded Context

A domain model is implemented within a bounded context. Each bounded context will have one software artifact. Ideally, one team is assigned to one bounded context and a separate source code repository exists for each bounded context.

Point #6 – Understand and Use Entity, Value Object, Aggregate, Domain Service

When you are implementing a domain model within a bounded context, you need to apply tactical DDD patterns including entity, value object, aggregate, and domain services.

You design your aggregates based on business requirements. Never design aggregates based on technical concerns like data access. Aggregate is basically the boundary of persistence and transaction. All interactions with an Aggregate should happen through the Root Entity.

Point #7 – Map An Aggregate to A Microservice

An aggregate is a good candidate for microservice. The microservice considers the transaction boundary of the aggregate. All operations involve single aggregate. Microservice has its own database to persist data that it needs. Transactions are local.

Point #8 – Map the Whole Bounded Context to A Microservice

Sometimes, operations may involve multiple aggregates in the same bounded context. In this case, you can map the whole bounded context to a microservice. Microservice has its own database to persist data that it needs. Transactions are local.

Point #9 – Understand The Difference Between Domain Service and Application Service

Sometimes you cannot place a business logic inside any particular domain objects. In that case, you can use domain service. Suppose you want to transfer funds between two account objects. In this case, you can place the fund transfer operation inside a domain service. If you are a Java programmer, you can think of a domain service as a Java class having one or more public operations performing business logic. Important point here is that domain services are stateless.

Now we will have a quick look at application services. Suppose a healthcare application sends an SMS notification to the doctor when a patient’s health conditions are too bad (determined by many factors). Here domain layer captures the red signal and contacts the application service to send the SMS notification to the concerned doctor. The application service sends the order for SMS notification to the infrastructure service. An infrastructure service takes care of the actual handling of SMS notifications.

Point #10 – Map Domain Service to A Microservice

You find domain business logic spans across multiple aggregates, and that logic are clubbed inside a domain service. Do you think clients may be interested in calling those operations directly for fulfilling a business purpose? If yes, you can plan to map the domain service to a microservice.

I have shared knowledge based on my understanding and experiences. If you find any significant errors or want to give me some feedback, feel free to contact me at maliksanjoykumar[@]gmail.com.