Edition 0 Updated to asp. Net core 0

Keep the microservice context boundaries relatively small 
Determining where to place boundaries between Bounded Contexts balances two competing goals. 
First, you want to initially create the smallest possible microservices, although that should not be the 
main driver; you should create a boundary around things that need cohesion. Second, you want to 
avoid chatty communications between microservices. These goals can contradict one another. You 
should balance them by decomposing the system into as many small microservices as you can until 
you see communication boundaries growing quickly with each additional attempt to separate a new 
Bounded Context. Cohesion is key within a single bounded context. 
It is similar to the 
Inappropriate Intimacy code smell
 when implementing classes. If two microservices 
need to collaborate a lot with each other, they should probably be the same microservice. 

---

195 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
Another way to look at this aspect is autonomy. If a microservice must rely on another service to 
directly service a request, it is not truly autonomous. 
Layers in DDD microservices 
Most enterprise applications with significant business and technical complexity are defined by 
multiple layers. The layers are a logical artifact, and are not related to the deployment of the service. 
They exist to help developers manage the complexity in the code. Different layers (like the domain 
model layer versus the presentation layer, etc.) might have different types, which mandate translations 
between those types. 
For example, an entity could be loaded from the database. Then part of that information, or an 
aggregation of information including additional data from other entities, can be sent to the client UI 
through a REST Web API. The point here is that the domain entity is contained within the domain 
model layer and should not be propagated to other areas that it does not belong to, like to the 
presentation layer. 
Additionally, you need to have always-valid entities (see the 
Designing validations in the domain 
model layer
 section) controlled by aggregate roots (root entities). Therefore, entities should not be 
bound to client views, because at the UI level some data might still not be validated. This reason is 
what the ViewModel is for. The ViewModel is a data model exclusively for presentation layer needs. 
The domain entities do not belong directly to the ViewModel. Instead, you need to translate between 
ViewModels and domain entities and vice versa. 
When tackling complexity, it is important to have a domain model controlled by aggregate roots that 
make sure that all the invariants and rules related to that group of entities (aggregate) are performed 
through a single entry-point or gate, the aggregate root. 
Figure 7-5 shows how a layered design is implemented in the eShopOnContainers application. 

---

196 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
Figure 7-5. DDD layers in the ordering microservice in eShopOnContainers 
The three layers in a DDD microservice like Ordering. Each layer is a VS project: Application layer is 
Ordering.API, Domain layer is Ordering.Domain and the Infrastructure layer is Ordering.Infrastructure. 
You want to design the system so that each layer communicates only with certain other layers. That 
approach may be easier to enforce if layers are implemented as different class libraries, because you 
can clearly identify what dependencies are set between libraries. For instance, the domain model layer 
should not take a dependency on any other layer (the domain model classes should be Plain Old Class 
Objects, or 
POCO
, classes). As shown in Figure 7-6, the