Microservice How to Model Services? Software Engineering II Sharif University of Technology MohammadAmin Fazli
Topics What makes a good service? The bounded context Communications in terms of business concepts Reading: Building Microservices-Sam Newman-Chapter III Modeling Services 2
What Makes a Good Service? Loose Coupling When services are loosely coupled, a change to one service should not require a change to another. A classic mistake is to pick an integration style that tightly binds one service to another. A loosely coupled service knows as little as it needs to about the services with which it collaborates. This also means we probably want to limit the number of different types of calls from one service to another, because beyond the potential performance problem, chatty communication can lead to tight coupling. High Cohesion We want related behavior to sit together, and unrelated behavior to sit elsewhere. If we want to change behavior, we want to be able to change it in one place, and release that change as soon as possible. Modeling Services 3
The Bounded Context Domain-Driven Design: focuses on how to create systems that model real-world domains. Ubiquitous language Repository abstraction Bounded Contexts … Bounded Context The idea is that any given domain consists of multiple bounded contexts, and residing within each are things that do not need to be communicated outside as well as things that are shared externally with other bounded contexts. a specific responsibility enforced by explicit boundaries If you want information from a bounded context, or want to make requests of functionality within a bounded context, you communicate with its explicit boundary using models. Like body cells Modeling Services 4
The Bounded Context MusicCorp example: We may or may not model all of that in our software, but that is nonetheless the domain in which we are operating. Warehouse Managing orders being shipped out (and the odd return) Taking delivery of new stock Having forklift truck races, … Finance department Manage payroll Keep the company accounts Produce important reports … Modeling Services 5
Shared & Hidden Models The finance department doesn ’ t need to know about the detailed inner workings of the warehouse. It does need to know some things, though — for example it needs to know about stock levels to keep the accounts up to date Modeling Services 6
Shared & Hidden Models We don ’ t need to blindly expose everything about the stock item from the warehouse context. There is the internal only representation, and the external representation we expose. Example: Finance doesn ’ t need to know where the stock item lives in the warehouse Sometimes we may encounter models with the same name that have very different meanings in different contexts too. Example: return which represents a customer sending something back For customer: printing a shipping label, dispatching a package, and waiting for a refund For warehouse: a package that is about to arrive and a stock item that needs to be restocked Modeling Services 7
Modules & Services Once you have found your bounded contexts in your domain, make sure they are modeled within your codebase as modules, with shared and hidden models. These modular boundaries are excellent candidates for microservices. Once you become very proficient, you may decide to skip the step of keeping the bounded context modeled as a module within a more monolithic system, and jump straight for a separate service. Getting service boundaries wrong can be costly, so waiting for things to stabilize as you get to grips with a new domain is sensible. Modeling Services 8
Premature Decomposition Prematurely decomposing a system into microservices can be costly, especially if you are new to the domain. In many ways, having an existing codebase you want to decompose into microservices is much easier than trying to go to microservices from the beginning Example: ThoughtWorks SnapCI and Go-CD Modeling Services 9
Business Capabilities When you start to think about the bounded contexts that exist in your organization, you should be thinking not in terms of data that is shared, but about the capabilities those contexts provide the rest of the domain. These capabilities may require the interchange of information (shared models) Ask first “ What does this context do? ” , and then “ So what data does it need to do that? ” Modeling Services 10 10
Turtles All the Way Down At the start, you will probably identify a number of coarse grained bounded contexts. But these bounded contexts can in turn contain further bounded contexts. Warehouse order fulfillment inventory management goods receiving When considering the boundaries of your microservices, first think in terms of the larger, coarser-grained contexts, and then subdivide along these nested contexts when you ’ re looking for the benefits of splitting out these seams Modeling Services 11 11
Turtles All the Way Down To the outside world, they are still making use of business capabilities in the warehouse, but they are unaware that their requests are actually being mapped transparently to two or more separate services Modeling Services 12 12
Turtles All the Way Down Sometimes, you will decide it makes more sense for the higher-level bounded context to not be explicitly modeled as a service boundary Modeling Services 13 13
Turtles All the Way Down Whether you choose the nested approach over the full separation approach should be based on your organizational structure. If order fulfillment, inventory management, and goods receiving are managed by different teams, they probably deserve their status as top-level microservices. Another reason to prefer the nested approach could be to chunk up your architecture to simplify testing. When testing services that consume the warehouse, I don ’ t have to stub each service inside the warehouse context, just the more coarsegrained API. Modeling Services 14 14
Communication in Terms of Business Concepts Changes come from business If our systems are decomposed along the bounded contexts that represent our domain, changes are more likely to be isolated to one, single microservice boundary. This reduces the number of places we need to make a change, and allows us to deploy that change quickly. It ’ s also important to think of the communication between these microservices in terms of the same business concepts The same terms and ideas that are shared between parts of your organization should be reflected in your interfaces. Modeling Services 15 15
The Technical Boundary Onion Architecture! The team needs to grow A logical decision delegates the responsibility of frontend to a remote team Changes frequently had to be made to both services. Both services spoke in terms of low-level, RPC- style method calls, which were overly brittle The service interface was also very chatty too, resulting in performance issues. This resulted in the need for elaborate RPC-batching mechanisms. Reason: ather than taking a vertical, business- focused slice through the stack, the team picked what was previously an in-process API and made a horizontal slice. This is not always a bad idea Modeling Services 16 16
Recommend
More recommend
