Microservice How to Model Services? Software Engineering II Sharif - - PowerPoint PPT Presentation

Microservice How to Model Services?

Software Engineering II Sharif University of Technology MohammadAmin Fazli

Modeling Services

Topics

 What makes a good service?  The bounded context  Communications in terms of business concepts  Reading:

 Building Microservices-Sam Newman-Chapter III

2

Modeling Services

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.

3

Modeling Services

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

• utside 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

• f functionality within a bounded context, you communicate with its explicit

boundary using models.

 Like body cells

4

Modeling Services

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  … 5

Modeling Services

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

6

Modeling Services

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

7

Modeling Services

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.

8

Modeling Services

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

9

Modeling Services

Business Capabilities

 When you start to think about the bounded contexts that

exist in your organization, you should be thinking not in terms

• f 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?”

10 10

Modeling Services

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

• ut these seams

11 11

Modeling Services

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

12 12

Modeling Services

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

13 13

Modeling Services

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.

14 14

Modeling Services

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

• rganization should be reflected in your interfaces.

15 15

Modeling Services

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 16 16