Microservices has 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 implement this design and it 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, as it could adopt frequent changes with significantly less effort and impact and fits well with 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.
Technologies to adopt
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
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 system.
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 Specification pattern, a service with distributed transaction can implement 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.