Microservices Architecture - the Domain Driven Approach

Microservices have proven to be the best way to implement scalable, resilient and distributed service-oriented architecture. It comes with a set of design principles that guides us how to size the services so that we don’t end up in creating a large(monolith) service. However, there are various ways and challenges to implementing this design and it is the discretion of the architect to choose the right approach that suits the business process. Tools and technologies are evolving very rapidly to address the challenges and requirements and hence we could anticipate significant changes to be adopted very frequently. Thanks to the nature of Microservices, it could adopt frequent changes with significantly less effort and impact and fits well with the agile development process.

If you decide to adopt Microservices, then there are many decisions to make. Here we will look at the basic principles, tools and technologies needed to build a Microservices architecture.

Design Principles

• Autonomous
• High Cohesion
• Resilience
• Data Consistency
• Automation

Technologies to adopt

• Communication (Synchronous and Asynchronous)
• Containerization
• Service Registration and Discovery
• Security
• Application Scaling and Management
• Centralized Monitoring and logging
• Configuration Management
• Container orchestration
• Infrastructure as Code
• Continuous Integration and Deployment Pipeline

The Domain Driven Approach

Domain Driven Design goes hand in hand with the Microservices architecture. The very first step towards Microservices architecture is deciding the boundaries for each service and DDD is all about defining the boundaries.

Architects need the help of domain experts to understand the domain and its internal dynamics in order to identify the boundaries. A domain analysis session must be conducted, preferably an event storming session, where the domain experts and technical team discuss together iteratively and explore the domain to identify the following

• Domain Events: Things that happened that are important and drive the business process.
• Commands: The event sources i.e. the actions raising the domain events. It can be a user action or a system-generated one.
• Ubiquitous language: Common business terminologies representing the semantics of the domain which must be used everywhere.
• Aggregate: Represents the state and behavior. Executes the operation that the command asks to perform and emits the corresponding events.
• Policies: Business rules that tell what should happen as a consequence of an event raised by a command. A set of policies combined form a business process.
• Bounded Context: A group of related aggregates and concepts from a bounded context. A bounded context draws the boundary and correlates to a Microservice.

From the domain knowledge gained from the Event Storming session a Business Process Model can be derived. Domain Driven Design combined with Business Process Modeling using Business Process Model and Notations (BPMN) could help us solve complex real-world problems and design highly cohesive distributed systems.

DDD should be applied only for Microservices with complex business rules. Simpler Microservices can be managed by simple approaches. Technical implementation of each Microservice can differ based on its requirement and functionality. For example, a Microservice can be as simple as a serverless function app in Azure, a service with more business rules and to avoid duplication can implement a Specification pattern, a service with a distributed transaction can implement an SAGA pattern or go for BPMN automation like Camunda, a service requiring high performance, scalability can implement CQRS pattern, an audit-related service could go for event sourcing etc.