Identify Microservices using Domain Driven Design(DDD)
As we all know that the biggest challenge in Micorservices architecture style is to identify the numbers of required microservices and to define the scope of microservices required in a bounded context. You may have read many articles related to implementing the domain driven design approach for the same but sometimes people gets confused with the terminologies and big technical words especially when you are new to DDD. So, you can refer this article where the things are explained in plain English and more simplified manner.
Points to be remembered:
- As we are now going to solve the business problem so don’t think about technical implementation details.
- It is very important to understand the business first before start working on the solution.
- It has been seen that the technical people start thinking about the solution and concentrating on architecture style or any pattern which they want to implement. So, have some patience and gain the business knowledge.
- Involve business expert in all discussion when Domain Driven Design technique.
Let's start identifying the bounded contexts and required Microservices:
- Understand the business and have a team discussion including business expert
- Note down all the business functions/areas which are required to solve the given business problem and you are good to go.
- Start grouping the identified business functions/areas and create as many as groups are possible.
- Identify the main group and write down the name of the group(business function/area) in the middle of the whiteboard.
- Similarly, start placing other groups into the white board and start mapping with the main group.
- Discuss again with team and refine groups.
- Group 1(Business function 1)
- Sub function
- Sub function 2
- Sub function 3
- Sub function 4
- Group 2 (Business function 2) – Core/Main
- Sub function 1
- Sub function 2
- Sub function 3
- Sub function 4
- Group 4 (Business function 3)
- Sub function 1
- Sub function 2
- Sub function 3
- Sub function 4
- Sub function 5
- Group 4 (Business function 4)
- Sub function 1
- Sub function 2
- Sub function 3
- Group 5 (Business function 1)
- Sub function 1
- Sub function 2
Discuss again on the created diagram and refine it until all agree on the same.
At last, separate the finally identified groups using dotted lines as shown below:
In this way, you have identified 5 Bounded Contexts at very high level where you need to design Microservices and you are ready for the next step in your solution designing of Microservices for each identified Bounded Context.
Always remember that there can be multiple Microservices in a Bounded Context. So, it can be said that a Microservice is a bounded context but not every Bounded Context is a Microservice.
Let's map with Domain Driven Design
Now, you are thinking where you have used domain driven design which is recommended approach. In fact, this article talks about Strategy phase of Domain driven design how let us see it again.
- When you were understanding the business problem, you were actually analyzing the domain (or in simple words the complete System).
- And, you involved business expert in all the discussion which is what we do in DDD and refer the business expert as the Domain expert, right?
- When you were noting down all the business functions/areas and sub-functions/areas, you were actually identifying the sub-domains (or in simple words the sub-system).
- We also identified core domain and other sub-domains, mapped these with their sub-functions in a rough diagram which we generally do in DDD to identify the boundary between context.
- After discussion with team, we identified the desired system and sub-systems, their functions and created the boundary, meaning identified the bounded contexts using DDD traditional approach.