01 Domain-Driven Design - Why Choose DDD for Microservices Design #

Hello, I am Olaf.

We know that during the process of microservice design, we often face the problem of how to define boundaries. I often see project teams arguing fiercely about how small a microservice should be. Different people will split microservices based on their own understanding of microservices, so everyone has their own opinions and no one can convince each other. They all think they are right.

In the actual implementation process, I have also seen many projects that, when faced with this confusion in microservice design, make decisions arbitrarily, which leads to significant operational pressure after going live. Is there a suitable theory or design method to guide microservice design? When you see the title of this lecture, I believe you already know the answer.

Indeed, it is DDD. So today, I will give you a detailed explanation of “Why Choose Domain-Driven Design for Microservice Design?”

Evolution of Software Architecture Patterns #

Before we dive into today’s topic, let’s first understand the background.

As we know, over the years, with the development of devices and new technologies, the architecture patterns of software have changed significantly. In general, software architecture patterns have gone through three stages: from monolithic to centralized, and to distributed microservices architecture. With the rapid rise of distributed technology, we have entered the era of microservices architecture.

We can use three steps to define the boundary of the domain model and microservices.

Step 1: In the event storming, we analyze user operations, events, external dependencies, and other elements in the business process, and based on these elements, we outline domain entities and other domain objects.

Step 2: Based on the business relationships between domain entities, we combine closely related entities to form aggregates, while determining the aggregate root, value objects, and entities within the aggregates. In this diagram, the boundaries between aggregates form the first layer of boundaries. They run in the same microservice instance and represent logical boundaries, hence represented by dashed lines.

Step 3: Based on business and semantic boundaries, we define one or more aggregates within a bounded context to form the domain model. In this diagram, the boundaries between bounded contexts form the second layer of boundaries. These boundaries may be the boundaries of future microservices, and the domain logic of different bounded contexts is isolated and runs in different microservice instances, physically isolated from each other. Therefore, these boundaries are physical boundaries and are represented by solid lines.

With these two layers of boundaries, designing microservices becomes easier.

In strategic design, we establish the domain model, define the boundaries of the business domain, establish a common language and bounded contexts, and determine the relationships between various domain objects in the domain model. At this point, the design work of the business domain model is basically completed, and this process also roughly determines the boundaries of the microservices on the application side.

In the process of implementing the transition from the business model to microservices, that is, from strategic design to tactical design, we establish a mapping relationship between the domain objects in the domain model and the code objects in the code model, binding the business architecture and the system architecture. When we respond to changes in the business and adjust the business architecture and domain model, the system architecture will also be adjusted accordingly, and new mapping relationships will be established simultaneously.

The Relationship between DDD and Microservices #

With the explanations above, let’s summarize the relationship between DDD and microservices again.

DDD is an architectural design approach, and microservices are an architectural style. Both are essentially means to pursue high responsiveness and separate the complexity of application system construction from a business perspective. Both emphasize starting from the business, and the core idea is to emphasize the reasonable division of domain boundaries and continuously adjust the existing architecture, optimize the existing code, in order to maintain the vitality of the architecture and code, which is what we often call evolutionary architecture.

DDD mainly focuses on: dividing domain boundaries from a business domain perspective, building a common language for efficient communication, establishing domain models through business abstraction, and maintaining logical consistency between business and code.

Microservices mainly focus on: inter-process communication, fault tolerance, and fault isolation at runtime, achieving decentralized data management and decentralized service governance. It focuses on the independent development, testing, construction, and deployment of microservices.

Conclusion #

Today we mainly discussed the challenges of microservice design and decomposition. Through DDD strategic design, we can establish domain models, define domain boundaries, and solve the problem of difficult boundary delineation in the process of microservice design. If your business focus is on the domain and domain logic, then you can choose DDD as the design method for microservices!

More importantly, DDD can not only be used for microservice design, but also for the design of enterprise middle platform. If your company is undergoing a transformation to a middle platform, DDD will be a powerful tool that can help you establish a very good enterprise-level middle platform business model. You will see more about this in the upcoming articles.

In addition, DDD tactical design requires relatively high requirements for designers and developers, and the implementation is relatively complex. There may be differences in the R&D management capabilities and personal development levels of different companies. Especially for traditional companies, there may be challenges and difficulties in the process of implementing tactical design. I suggest that if you and your company have such ideas, you must carefully evaluate your capabilities and choose the most suitable method to implement DDD.

It is also worth weighing the benefits according to the gains. Overall, DDD can bring you the following benefits:

1. DDD is a complete and systematic design method. It can provide you with a standard design process from strategic design to tactical design, making your design ideas clearer and the design process more standardized.
2. DDD is good at dealing with product development with high complexity related to the domain. Through DDD, you can establish a core and stable domain model, which is conducive to the transfer and inheritance of domain knowledge.
3. DDD emphasizes the collaboration between teams and domain experts, which can help your team establish good communication atmosphere and build a consistent architecture system.
4. The design concepts, principles, and patterns of DDD can help improve your architectural design capabilities.
5. Whether designing microservices in a new project or evolving a system from a monolithic architecture to microservices, DDD’s architectural principles can be followed.
6. DDD is not only applicable to microservices, but also to traditional monolithic applications.