Edition 0 Updated to asp. Net core 0

Partitioning the microservices
. Finally, no matter, which approach you take for your microservice 
architecture, another challenge is deciding how to partition an end-to-end application into multiple 
microservices. As noted in the architecture section of the guide, there are several techniques and 
approaches you can take. Basically, you need to identify areas of the application that are decoupled 
from the other areas and that have a low number of hard dependencies. In many cases, this approach 
is aligned to partitioning services by use case. For example, in our e-shop application, we have an 
ordering service that is responsible for all the business logic related to the order process. We also 
have the catalog service and the basket service that implement other capabilities. Ideally, each service 
should have only a small set of responsibilities. This approach is similar to the single responsibility 
principle (SRP) applied to classes, which states that a class should only have one reason to change. But 
in this case, it is about microservices, so the scope will be larger than a single class. Most of all, a 
microservice has to be autonomous, end to end, including responsibility for its own data sources. 
External versus internal architecture and design patterns 
The external architecture is the microservice architecture composed by multiple services, following the 
principles described in the architecture section of this guide. However, depending on the nature of 
each microservice, and independently of high-level microservice architecture you choose, it is 
common and sometimes advisable to have different internal architectures, each based on different 
patterns, for different microservices. The microservices can even use different technologies and 
programming languages. Figure 6-2 illustrates this diversity. 

---

100 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Figure 6-2. External versus internal architecture and design 
For instance, in our 
eShopOnContainers
sample, the catalog, basket, and user profile microservices are 
simple (basically, CRUD subsystems). Therefore, their internal architecture and design is 
straightforward. However, you might have other microservices, such as the ordering microservice, 
which is more complex and represents ever-changing business rules with a high degree of domain 
complexity. In cases like these, you might want to implement more advanced patterns within a 
particular microservice, like the ones defined with domain-driven design (DDD) approaches, as we are 
doing in the 
eShopOnContainers
ordering microservice. (We will review these DDD patterns in the 
section later that explains the implementation of the 
eShopOnContainers
ordering microservice.) 
Another reason for a different technology per microservice might be the nature of each microservice. 
For example, it might be better to use a functional programming language like F#, or even a language 
like R if you are targeting AI and machine learning domains, instead of a more object-oriented 
programming language like C#. 
The bottom line is that each microservice can have a different internal architecture based on different 
design patterns. Not all microservices should be implemented using advanced DDD patterns, because 
that would be over-engineering them. Similarly, complex microservices with ever-changing business 
logic should not be implemented as CRUD components, or you can end up with low-quality code.