NET-Microservices-Architecture-for-Containerized-NET-Applications

As Figure 4-8 shows, the catalog business microservice could be composed of several services or
processes. These could be multiple ASP.NET Web API services or any other kind of services using
HTTP or any other protocol. More importantly, the services could share the same data, as long as
these services are cohesive with respect to the same business domain.
Figure 4-8. Business microservice with several physical services
The services in the example share the same data model because the Web API service targets the same
data as the Search service. So, in the physical implementation of the business microservice, you’re
splitting that functionality so you can scale each of those internal services up or down as needed.
Maybe the Web API service usually needs more instances than the Search service, or vice versa.
In short, the logical architecture of microservices doesn’t always have to coincide with the physical
deployment architecture. In this guide, whenever we mention a microservice, we mean a business or
logical microservice that could map to one or more (physical) services. In most cases, this will be a
single service, but it might be more.
Challenges and solutions for distributed data
management
Challenge #1: How to define the boundaries of each microservice
Defining microservice boundaries is probably the first challenge anyone encounters. Each microservice
has to be a piece of your application and each microservice should be autonomous with all the
benefits and challenges that it conveys. But how do you identify those boundaries?
First, you need to focus on the application’s logical domain models and related data. Try to identify
decoupled islands of data and different contexts within the same application. Each context could have
a different business language (different business terms). The contexts should be defined and managed
independently. The terms and entities that are used in those different contexts might sound similar,
but you might discover that in a particular context, a business concept with one is used for a different
31 CHAPTER 3 | Architecting container and microservice-based applications