Steps to Effective Microservices Design
Filipe is a Senior Solutions Architect at Affinity. With a…
Microservices is an architectural style that creates applications that are resilient, highly scalable, independently deployable, and capable of rapidly evolving. However, a good microservices architecture requires a different approach when it comes to designing and building applications, which brings enormous benefits and some challenges.
Microservices architecture consists of a collection of small autonomous services. Each service is independent and must implement a single business capability in a linked context. A linked context is a natural division within an enterprise and provides an explicit boundary within which a domain model exists.
Therefore, we must follow some steps to define the limits of microservices. Do you want to know which ones?
- Guidance by Business Domain;
- Tactical DDD; Tactical Domain-Driven Design
- Identifying Application Microservices
Step 1: Guidance by Business Domain
During the strategic phase, we have some challenges and some elements to consider. One of the first and biggest challenges with microservices is defining the boundaries of individual services. The general rule is that a service should do “one thing”, however in practice this rule requires careful consideration. There is no mechanical process that produces the “right” design. You will have to think deeply about your business domain, requirements, and goals.
Domain-based framework (DDD) provides a framework that can help you go most of the way to a well-structured set of microservices. DDD has two distinct phases: strategic and tactical.
Strategic DDD helps ensure that the architecture remains focused on business capabilities. Tactical DDD provides a set of design patterns that you can use to create your domain model.
It starts by analyzing the business domain to understand the functional requirements of the application. The output of this step is an informal description of the domain, which can be improved into a more formal set of domain models.
It then defines the domain’s linked contexts. Each linked context contains a domain model that represents a specific subdomain of the larger application.
Within a linked context, apply tactical DDD patterns to define entities, aggregates, and domain services.
Use the results from the previous step to identify the microservices in your application.
Step 2: Tactical Domain-Driven Design (DDD)
Tactical DDD defines domain models more precisely. In this phase, the following are identified and defined:
- Entities;
- Value Objects (value objects);
- Aggregations (aggregates);
- Domain and Application Services;
- Domain events (domain events).
Step 3: Identifying Application Microservices
It starts with a linked context. Functionality in a microservice should not span more than one linked context. By definition, a linked context marks the boundary of a specific domain model. If you find that a microservice combines different domain models together, then you may need to go back and refine your domain analysis.
It then looks at the aggregations in the domain model. Aggregations are often good candidates for microservices. A well-designed aggregation exhibits many of the characteristics of a well-designed microservice, such as:
- An aggregation derives from business requirements rather than technical issues such as data access or messaging.
- An aggregation must have high functional cohesion.
- Aggregation is a persistence boundary.
- Aggregations must be loosely conjugated.
Domain services are also good candidates for microservices. Domain services are stateless operations across multiple aggregates. A typical example is a workflow involving multiple microservices.
Finally, it considers non-functional requirements. It looks at factors such as team size, data types, technologies, scalability requirements, availability requirements, and security requirements. These factors can lead you to further decompose a microservice into two or more smaller services or to do the opposite and combine multiple microservices into one.
Other sources:
- https://learn.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis
- https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-ddd
- https://learn.microsoft.com/en-us/azure/architecture/microservices/model/microservice-boundaries
About Affinity
Affinity is a consulting company specialized in information technologies, focused on people and with the assumed proposition of offering valuable business and career experiences for its community of global talent and partners. Discover more about us:
- More about the way we handle Nearshore partnerships here.
- Hit us with your IT Nearshore needs here.
- See what our clients have to say about us here.
What's Your Reaction?
Filipe is a Senior Solutions Architect at Affinity. With a vast international experience in software development, Filipe never says no to a challenge, having embraced this author's experience as if it was music! Filipe is a drummer, guitarist and bassist – the true polyglot of music. Video games are a hobby and new movies and series never leave his sight!