NET-Microservices-Architecture-for-Containerized-NET-Applications-(Microsoft-eBook)

application. This approach provides a way to easily write a query that combines data from multiple
tables.
However, data access becomes much more complex when you move to a microservices architecture.
But even when ACID transactions can or should be used within a microservice or Bounded Context,
the data owned by each microservice is private to that microservice and can only be accessed via its
microservice API. Encapsulating the data ensures that the microservices are loosely coupled and can
evolve independently of one another. If multiple services were accessing the same data, schema
updates would require coordinated updates to all the services. This would break the microservice
lifecycle autonomy. But distributed data structures mean that you cannot make a single ACID
transaction across microservices. This in turn means you must use eventual consistency when a
business process spans multiple microservices. This is much harder to implement than simple SQL
joins, because you can’t create integrity constraints or use distributed transactions between separate
databases, as we’ll explain later on. Similarly, many other relational database features are not available
across multiple microservices.
Going even further, different microservices often use different kinds of databases. Modern
applications store and process diverse kinds of data, and a relational database is not always the best
choice. For some use cases, a NoSQL database such as Azure DocumentDB or MongoDB might have a
more convenient data model and offer better performance and scalability than a SQL database like
SQL Server or Azure SQL Database. In other cases, a relational database is still the best approach.
Therefore, microservices-based applications often use a mixture of SQL and NoSQL databases, which
is sometimes called the polyglot persistence approach.
A partitioned, polyglot-persistent architecture for data storage has many benefits. These include
loosely coupled services and better performance, scalability, costs, and manageability. However, it can
introduce some distributed data management challenges, as we will explain in “Identifying domainmodel
boundaries” later in this chapter.
The relationship between microservices and the Bounded Context
pattern
The concept of microservice derives from the Bounded Context (BC) pattern in domain-driven design
(DDD). DDD deals with large models by dividing them into multiple BCs and being explicit about their
boundaries. Each BC must have its own model and database; likewise, each microservice owns its related
data. In addition, each BC usually has its own ubiquitous language to help communication between
software developers and domain experts.
Those terms (mainly domain entities) in the ubiquitous language can have different names in different
Bounded Contexts, even when different domain entities share the same identity (that is, the unique ID
that is used to read the entity from storage). For instance, in a user-profile Bounded Context, the User
domain entity might share identity with the Buyer domain entity in the ordering Bounded Context.
A microservice is therefore like a Bounded Context, but it also specifies that it is a distributed service.
It is built as a separate process for each Bounded Context, and it must use the distributed protocols
noted earlier, like HTTP/HTTPS, WebSockets, or AMQP. The Bounded Context pattern, however, does
not specify whether the Bounded Context is a distributed service or if it is simply a logical boundary
(such as a generic subsystem) within a monolithic-deployment application.
30 Architecting Container- and Microservice-Based Applications