Each service is small enough that it can be built by a small team working independently.If splitting functionality into two services causes them to be overly chatty, it may be a symptom that these functions belong in the same service. There are no chatty calls between services.Each service has a single responsibility.
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.Īfter you identify the microservices in your application, validate your design against the following criteria: Look at factors such as team size, data types, technologies, scalability requirements, availability requirements, and security requirements. We'll see an example of this in the Drone Delivery application.įinally, consider non-functional requirements. A typical example is a workflow that involves several microservices. Domain services are stateless operations across multiple aggregates.
Next, look at the aggregates in your domain model. If you find that a microservice mixes different domain models together, that's a sign that you may need to go back and refine your domain analysis. By definition, a bounded context marks the boundary of a particular domain model. In general, the functionality in a microservice should not span more than one bounded context. Here's an approach that you can use to derive microservices from the domain model. Now we're ready to go from domain model to application design. Then we looked more closely at one of these bounded contexts, the Shipping bounded context, and identified a set of entities, aggregates, and domain services for that bounded context. In the previous article, we defined a set of bounded contexts for a Drone Delivery application. You can read more about the scenario and the corresponding reference implementation here. This article uses a drone delivery service as a running example. But if you start from a carefully designed domain model, it's much easier to reason about microservices.
What is the right size for a microservice? You often hear something to the effect of, "not too big and not too small" - and while that's certainly correct, it's not very helpful in practice.
0 kommentar(er)
