Edition 0 Updated to asp. Net core 0

Additional resources 
•
CAP theorem
https://en.wikipedia.org/wiki/CAP_theorem
 
•
Eventual consistency
https://en.wikipedia.org/wiki/Eventual_consistency
 
•
Data Consistency Primer
https://learn.microsoft.com/previous-versions/msp-n-p/dn589800(v=pandp.10)
 
•
Martin Fowler. CQRS (Command and Query Responsibility Segregation)
https://martinfowler.com/bliki/CQRS.html
 
•
Materialized View
https://learn.microsoft.com/azure/architecture/patterns/materialized-view
 
•
Charles Row. ACID vs. BASE: The Shifting pH of Database Transaction Processing
https://www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/
 
•
Compensating Transaction
https://learn.microsoft.com/azure/architecture/patterns/compensating-transaction
 
•
Udi Dahan. Service Oriented Composition
https://udidahan.com/2014/07/30/service-oriented-composition-with-video/
 
Identify domain-model boundaries for each 
microservice 
The goal when identifying model boundaries and size for each microservice isn’t to get to the most 
granular separation possible, although you should tend toward small microservices if possible. 
Instead, your goal should be to get to the most meaningful separation guided by your domain 
knowledge. The emphasis isn’t on the size, but instead on business capabilities. In addition, if there’s 
clear cohesion needed for a certain area of the application based on a high number of dependencies, 
that indicates the need for a single microservice, too. Cohesion is a way to identify how to break apart 
or group together microservices. Ultimately, while you gain more knowledge about the domain, you 
should adapt the size of your microservice, iteratively. Finding the right size isn’t a one
-shot process. 

---

37 
CHAPTER 3 | Architecting container and microservice-based applications 
Sam Newman
, a recognized promoter of microservices and author of the book 
Building Microservices
, 
highlights that you should design your microservices based on the Bounded Context (BC) pattern 
(part of domain-driven design), as introduced earlier. Sometimes, a BC could be composed of several 
physical services, but not vice versa. 
A domain model with specific domain entities applies within a concrete BC or microservice. A BC 
delimits the applicability of a domain model and gives developer team members a clear and shared 
understanding of what must be cohesive and what can be developed independently. These are the 
same goals for microservices. 
Another tool that informs your design choice is 
Conway’s law
, which states that an application will 
reflect the social boundaries of the organization that produced it. But sometimes the opposite is true -
the company’s organization is formed by the software. You might need to reverse Conway’s law and 
build the boundaries the way you want the company to be organized, leaning toward business 
process consulting. 
To identify bounded contexts, you can use a DDD pattern called the 
Context Mapping pattern
. With 
Context Mapping, you identify the various contexts in the application and thei
r boundaries. It’s 
common to have a different context and boundary for each small subsystem, for instance. The Context 
Map is a way to define and make explicit those boundaries between domains. A BC is autonomous 
and includes the details of a single domain -details like the domain entities- and defines integration 
contracts with other BCs. This is similar to the definition of a microservice: it’s autonomous, it 
implements certain domain capability, and it must provide interfaces. This is why Context Mapping 
and the Bounded Context pattern are good approaches for identifying the domain model boundaries 
of your microservices. 
When designing a large application, you’ll see how its domain model can be fragmented 
- a domain 
expert from the catalog domain will name entities differently in the catalog and inventory domains 
than a shipping domain expert, for instance. Or the user domain entity might be different in size and 
number of attributes when dealing with a CRM expert who wants to store every detail about the 
customer than for an ordering domain expert who just needs partial data about the customer. It’s very 
hard to disambiguate all domain terms across all the domains related to a large application. But the 
most important thing is that you shouldn’t try to uni
fy the terms. Instead, accept the differences and 
richness provided by each domain. If you try to have a unified database for the whole application, 
attempts at a unified vocabulary will be awkward and won’t sound right to any of the multiple domain 
experts. Therefore, BCs (implemented as microservices) will help you to clarify where you can use 
certain domain terms and where you’ll need to split the system and create additional BCs with 
different domains. 
You’ll know that you got the right 
boundaries and sizes of each BC and domain model if you have few 
strong relationships between domain models, and you do not usually need to merge information 
from multiple domain models when performing typical application operations. 
Perhaps the best answer to the question of how large a domain model for each microservice should 
be is the following: it should have an autonomous BC, as isolated as possible, that enables you to 
work without having to constantly switch to other contexts (other microservice’s m
odels). In Figure 4-
10, you can see how multiple microservices (multiple BCs) each has their own model and how their 

---

38 
CHAPTER 3 | Architecting container and microservice-based applications 
entities can be defined, depending on the specific requirements for each of the identified domains in 
your application.