Scribd
Upload
19 views15 pages

How To Model Services

This document discusses key concepts for modeling microservices, including loose coupling, high cohesion, and bounded contexts. It recommends: 1) Defining bounded contexts for each business capability and enforcing explicit boundaries between contexts using shared and hidden models. 2) Avoiding premature decomposition and only splitting services along modular or technical boundaries to minimize coupling. 3) Modeling software architecture after the business domain by representing business concepts as microservices and granulating larger contexts into finer-grained services.

Uploaded by

abhijeet
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
19 views15 pages

How To Model Services

This document discusses key concepts for modeling microservices, including loose coupling, high cohesion, and bounded contexts. It recommends: 1) Defining bounded contexts for each business capability and enforcing explicit boundaries between contexts using shared and hidden models. 2) Avoiding premature decomposition and only splitting services along modular or technical boundaries to minimize coupling. 3) Modeling software architecture after the business domain by representing business concepts as microservices and granulating larger contexts into finer-grained services.

Uploaded by

abhijeet
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

How to Model

Services

By Abhijeet Gole
Autonomous
Autonomous
• Failure is first step to
success
What Makes a
Good Service? • key concepts
• loose coupling
• high cohesion
• When services are loosely coupled, a change to
one service should not require a change to
another.
• The whole point of a microservice is being able to
make a change to one service and deploy it,
Loose Coupling without needing to change any other part of the
system.
• A loosely coupled service knows as little as it
needs to about the services with which it
collaborates.
• We want related behavior to sit together,
and unrelated behavior to sit elsewhere.
• Making changes in lots of different
High Cohesion places is slower, and deploying lots of
services at once is risky—both of which
we want to avoid.
• Things that do not need to be communicated outside
as well as things that are shared externally with
other bounded contexts
The Bounded • Each bounded context has an explicit interface,
where it decides what models to share with other
Context contexts.
• A specific responsibility enforced by explicit
boundaries
Shared and Hidden Models
Shared model between Warehouse and Finance
• Identify what model to share and which
ones to hide
Modules and • Helps to avoid tight coupling

Services • These modular boundaries are excellent


candidates for microservices.
• Prematurely decomposing a system into
microservices can be costly, especially if
you are new to the domain.
Premature • having an existing codebase you want to
Decomposition decompose into microservices is much
easier than trying to go to microservices
from the beginning.
• Eg- SnapCI and Go-CD
Business Capabilities

The bounded contexts inside the warehouse being Microservices representing nested bounded
popped up into their own top-level contexts contexts hidden inside the warehouse

• Granulate larger coarser grains into finer ones


Communication in • Adapting to every changing environment is
very important
Terms of Business • The modeling of your software after your
Concepts business domain shouldn’t stop at the idea
of bounded contexts
Technical
Boundaries

A service boundary split across a


technical seam

You might also like