Scribd
Upload
28 views2 pages

Microservice Architectures: DDD and Microservices

The document discusses the challenges of defining boundaries in microservice architectures and emphasizes the importance of a well-designed domain model. It suggests that microservices should be organized around business capabilities and highlights the need for loose coupling and cohesion among services. Additionally, it outlines steps for using domain-driven design to identify microservices, including analyzing bounded contexts and aggregates, while considering nonfunctional requirements and the role of domain events in communication.

Uploaded by

Teodora037
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
28 views2 pages

Microservice Architectures: DDD and Microservices

The document discusses the challenges of defining boundaries in microservice architectures and emphasizes the importance of a well-designed domain model. It suggests that microservices should be organized around business capabilities and highlights the need for loose coupling and cohesion among services. Additionally, it outlines steps for using domain-driven design to identify microservices, including analyzing bounded contexts and aggregates, while considering nonfunctional requirements and the role of domain events in communication.

Uploaded by

Teodora037
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Microservice Architectures: DDD and Microservices

The reason for this is that one of the biggest challenges of microservices is to define the boundaries of
individual services. A well looking domain model design can help to find those boundaries.
A general rule on microservice boundaries is that a service should do one thing. But putting that rule into
practice requires careful sort. There is no real mechanism or process that will produce the right design.
You have to think deeply about your domain, the applications requirements and the goals of your project.
Microservices should be designed around capabilities, for instance business capabilities. For instance, in
an online shopping domain, order management and shipping are business capabilities. The easiest
service design thus would be to map the business capabilities directly to services. For instance, in the
example to design an order service and a shipping service. This approach in general provides a better
starting point than designing services around horizontal layers such as data access or messaging. But
please note that it is only a starting point. Usually, careful design is needed to get the service cut right.
Many other considerations need to be taken into account. For example, microservices should be loosely
coupled and not every possible service cut leads to a loosely coupled architecture. A microservice
architecture exhibits a good loose coupling if you can change one service without requiring other services
to be changed at the same time.
At the same time, microservices should be cohesive. That is, they should have a single, well-defined
purpose. They should abstract and encapsulate the details of the domain knowledge and offer it via an API
abstraction to their clients.
You want to avoid chatty calls between services. If the interaction between two services is overly chatty, it
may be a symptom that these functions belong in the same service.
Each service should be small enough that it can be built by a small team working on it independently.
Oftentimes, business capabilities are too big to be represented by a single service that can be built and
maintained by a small team and thus need to be broken down before they are mapped to services.

Each service should be independently deployable. That is, there should be no interdependencies that will
require that two or more services need to be deployed together. Each service should be deployable without
redeploying other services.
Finally, service boundaries should not create problems with data consistency or integrity. For example, if
some strong consistency is really needed, it might make sense to consider co-locating the domain objects
that need strong consistency in one service. Before doing that, of course you should consider do you really
need the strong consistency
There are quite a number of requirements on microservice boundaries and finding the right service cut.
Very often it's hard to find an optimal solution so a compromise has to be found. Here a good domain
driven design can help. Possible steps for using domain driven design in microservice identification are:
Initially you analyze your domain as usual in domain driven design. Then as usual, you define your bounded
contexts. Based on the bounded contexts you define entities, aggregates and services. Using those four
1
kinds of domain model elements, bounded contexts, entities, aggregates and services, you identify the
microservices. This is usually not a linear process as depicted here, but every step might require
refinements in any previous step.
In this you should consider that microservices communicates through well-defined APIs. This approach
corresponds well to the two patterns open host service and published language. So, to find microservice
APIs you should design those two patterns into your bounded context relationships where appropriate.
Then next you can start identifying microservice boundaries. Initially you analyze a bounded context. In
general, the functionality in a microservice should not spend more than one bounded context. Next you
should analyze the aggregates in the domain model. Aggregates are good candidates for microservices,
and aggregate routes are good candidates for microservice API resources. This is because aggregates
already naturally fulfill many requirements, we expect for microservice boundaries. And aggregate is
derived from business requirements rather than technical concerns, and aggregate should have high
functional cohesion and aggregate is a boundary of persistence and it should be loosely coupled. Domain
services are also good alternative candidates for microservices. They represent stateless operations,
often across multiple aggregates. Finally, also consider nonfunctional requirements when looking for
microservices. Consider factors such as team sites, data types, technologies, scalability requirements,
availability requirements, and security requirements. These factors may lead you to further decompose a
microservice into two or more smaller services or do the opposite and combine several microservices into
one.
Last but not least, you should also consider the role of domain events. They are for instance important in
designing the event driven communication among the microservices. That is, domain events can be used
to notify other parts of the system when something happens. As the name suggests, the main events
should mean something within the domain.
Domain events are especially relevant in a microservice architecture. Because microservices are
distributed and don't share data stores, domain events provide a way for microservices to coordinate with
each other.
In this context, we should mention event storming. Event storming is a collaborative activity where you
bring together domain experts and technical architects and designers to discover the ubiquitous language
of a system or context. As the name event storming suggests, it is centered around finding and designing
domain events. The intention is to try to capture a system in terms of the things that happen, the events.

You might also like