Edition 0 Updated to asp. Net core 0

Figure 4-10. Identifying entities and microservice model boundaries 
Figure 4-10 illustrates a sample scenario related to an online conference management system. The 
same entity appears as “Users”, “Buyers”, “Payers”, and “Customers” depending on the bounded 
context. Yo
u’ve identified several BCs that could be implemented as microservices, based on domains 
that domain experts defined for you. As you can see, there are entities that are present just in a single 
microservice model, like Payments in the Payment microservice. Those will be easy to implement. 
However, you might also have entities that have a different shape but share the same identity across 
the multiple domain models from the multiple microservices. For example, the User entity is identified 
in the Conferences Management microservice. That same user, with the same identity, is the one 
named Buyers in the Ordering microservice, or the one named Payer in the Payment microservice, and 
even the one named Customer in the Customer Service microservice. This is because, depending on 
the 
ubiquitous language
 that each domain expert is using, a user might have a different perspective 
even with different attributes. The user entity in the microservice model named Conferences 
Management might have most of its personal data attributes. However, that same user in the shape of 
Payer in the microservice Payment or in the shape of Customer in the microservice Customer Service 
might not need the same list of attributes. 
A similar approach is illustrated in Figure 4-11. 

---

39 
CHAPTER 3 | Architecting container and microservice-based applications 
Figure 4-11. Decomposing traditional data models into multiple domain models 
When decomposing a traditional data model between bounded contexts, you can have different 
entities that share the same identity (a buyer is also a user) with different attributes in each bounded 
context. You can see how the user is present in the Conferences Management microservice model as 
the User entity and is also present in the form of the Buyer entity in the Pricing microservice, with 
alternate attributes or details about the user when it’s actually a buyer. Each microservice or BC might 
not need all the data related to a User entity, just part of it, depending on the problem to solve or the 
context. For instance, in the Pricing microservice model, you do not need the address or the name of 
the user, just the ID (as identity) and Status, which will have an impact on discounts when pricing the 
seats per buyer. 
The Seat entity has the same name but different attributes in each domain model. However, Seat 
shares identity based on the same ID, as happens with User and Buyer. 
Basically, there’s a shared concept of a user that exists in multiple services (domains), which all share 
the identity of that user. But in each domain model there might be additional or different details 
about the user entity. Therefore, there needs to be a way to map a user entity from one domain 
(microservice) to another. 
There are several benefits to not sharing the same user entity with the same number of attributes 
across domains. One benefit is to reduce duplication, so that microservice models do not have any 
data that they do not need. Another benefit is having a primary microservice that owns a certain type 
of data per entity so that updates and queries for that type of data are driven only by that 
microservice. 

---

40 
CHAPTER 3 | Architecting container and microservice-based applications 
The API gateway pattern versus the Direct client-to-
microservice communication 
In a microservices architecture, each microservice exposes a set of (typically) fine-grained endpoints. 
This fact can impact the client-to-microservice communication, as explained in this section.