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.
Dostları ilə paylaş: