Breaking the Monolith: A Domain-Driven Path to Microservices

Before we learn about domain-driven design, let's understand why we use microservices. Not all apps require them. The decision should depends on the needs of the application

Why Microservices?
Microservices offer several advantages over a monolithic system(It comes with a cost and this post is not meant to discuss that)

However, there is no specific number of microservices to aim for. The goal is to meet the expectations for each service.

The Need for Domain-Driven Design (DDD) DDD is a suitable approach for determining how many microservices are required when breaking down a monolithic system

Let’s walk through the process of architecting a chat application with microservices, using Domain-Driven Design .

The first step always is to

1.Understand the Domain:

Begin by thoroughly understanding the domain.
Sit with domain experts and users to clarify the problem statement you want to solve.

2.Come up with Subdomains:

-Identify subdomains, as each subdomain has the potential to become a microservice.

• Use event storming to identify subdomains. In event storming, domain experts, decision-makers, developers, and testers collaborate.
• The team brainstorms and lists all possible events within the domain. For the chat application example, events could include user registration, user login, message sent, message delivered, and message deleted.
• Sequence the events and identify any missing events. For instance, after a user logs in, they might either log out or send a message. After a message is sent, events like message received and message delivered can occur.

3.Identify Bounded Contexts:

• Determine bounded contexts, where the context of an object within a boundary might differ from the same object in another boundary. Group logically related events into a single bounded context.
• For instance, user registration, login, and logout can be grouped into a "user management" bounded context, where the user object relates to authentication, authorization, and permissions. Message sent, delivered, and deleted events can form a "message" bounded context, where the message object contains content, sender information, and status (pending, delivered, deleted).
• A "notification" bounded context might include a "user notified" event. Even if a user object is present in both the user management and notification contexts, the user object may have different meanings. In user management, it relates to authentication and authorization, while in notifications, it might only involve a user ID and notification status.

4.Develop Microservices:

• For each bounded context, consider developing a microservice.
• For the user management bounded context, you might have a user management microservice. Similarly, for the message and notification bounded contexts, you could create message and notification microservices.
• If multiple events within a bounded context operate on the same object, you may only need one microservice for that bounded context.

The 2 things to take ensure during development are

Ensure Microservice Principles:

• Each microservice should adhere to principles such as loose coupling, independent scaling, and less communication overhead.

Avoid Distributed Monoliths:

• Ensure that the resulting microservices architecture does not become a distributed monolith, where tight coupling and dependencies negate the benefits of microservices.

There are numerous other approaches to split a monolithic application into a microservice and its not mandatory that you follow DDD principles