MICROSERVICE

ARCHITECTURE
Memodelkan Kebutuhan Sistem Dengan
Pendekatan Microservice

Andri Santoso, S.Kom., M.Sc.

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya

Case Study: MusicCorp
• MusicCorp → the cutting-edge online retailer
• MusicCorp was recently a brick-and-mortar retailer, but after the bottom
dropped out of the gramophone record business it focused more and
more of its efforts online.
• The company has a website but feels that now is the time to double-down
on the online world.
• It has decided that its best chance of taking over the world is by making
sure it can make changes as easily as possible.
• Microservices for the win!

Fakultas Ilmu Komputer Universitas Brawijaya

What Makes a Good Service?
• Loose Coupling and High Cohesion
• They are all for naught if we get these two things wrong.

Fakultas Ilmu Komputer Universitas Brawijaya

Loose Coupling
• The whole point of a microservice is being able to make a change to one
service and deploy it, without needing to change any other part of the
system.
• What sort of things cause tight coupling?
Picking an integration style that tightly binds one service to another
• causing changes inside the service to require a change to consumers (discussed
more in Integration chapter)
• A loosely coupled service knows as little as it needs to about the services
with which it collaborates.
• Limit the number of calls from one service to another!

Fakultas Ilmu Komputer Universitas Brawijaya

High Cohesion
• Related behavior need to sit together, and unrelated behavior to sit
elsewhere
• Low Cohesion Problem:
• The change of behavior in lots of different places, will make us to release lots of
different services (perhaps at the same time).
• Making changes in lots of different places is slower, and deploying lots of services
at once is risky
• Find boundaries within our problem domain that help ensure that related
behavior is in one place

Fakultas Ilmu Komputer Universitas Brawijaya

The Bounded Context
• Bounded Context: “a specific responsibility enforced by explicit boundaries.”
• Any given domain consists of multiple bounded contexts, and residing within
each are models
• 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.
• MusicCorp business Example:
• Domain: the whole business in which we are operating (covers everything from the
warehouse to the reception desk).
• Warehouse activities: managing orders being shipped out (and the odd return), taking
delivery of new stock, etc.
• Finance department activities: manage payroll, keep the company accounts, and produce
important reports.
• Finance department and the warehouse are two separate bounded contexts.

Fakultas Ilmu Komputer Universitas Brawijaya

Shared and Hidden Models
• For MusicCorp, the finance
department and the warehouse
both have:
• explicit interface to the outside world
(in terms of inventory reports, pay
slips, etc.),
• details that only they need to know
about (forklift trucks, calculators).
• The finance department doesn’t
need to know about the detailed • Stock item then becomes a shared model between
inner workings of the warehouse. the two contexts.
• We don’t need to blindly expose everything about
• ONLY need to know some things, like: the stock item from the warehouse context.
stock levels to keep the accounts up • There is the internal-only representation, and the
to date. external representation we expose.

Fakultas Ilmu Komputer Universitas Brawijaya

Modules and Services
• Thinking clearly about what models should be shared, and not sharing our
internal representations → we can avoid tight coupling
• (Review Chapter 1) We have the option of using modules within a process
boundary to keep related code together and attempt to reduce the
coupling to other modules in the system.
• 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 then become excellent candidates for
microservices.
• ⚠Once you become very proficient, you may decide to skip the step of
creating modules → jump straight for a separate service.

Fakultas Ilmu Komputer Universitas Brawijaya

Premature Decomposition
• The initial take on the service boundaries can be “not quite right”.
• This led to lots of changes being made across services, and an associated high cost
of change.
• Example:
1. The services are decomposed prematurely (many boundaries are not stable)
2. Then, the services merged back into one monolithic system, giving time to better understand
where the boundaries should exist
3. The team was then able to split the monolithic system apart into microservices, whose
boundaries proved to be much more stable.
• Prematurely decomposing a system into microservices can be costly
• Having an existing codebase that you want to decompose into
microservices is much easier than trying to go to microservices from the
beginning.

Fakultas Ilmu Komputer Universitas Brawijaya

Business Capabilities
Thinking about bounded Thinking about the capabilities ⚠ You should not be
contexts that exist in your
organization = those contexts provide the rest of
the domain.
thinking in terms of
data that is shared

• Example:
• The warehouse may provide the capability to get a current stock list
• The Finance context may well expose the end-of-month accounts or let you set up payroll for a
recruit.
• These capabilities may require the interchange of information (shared models)
• Thinking about data leads to merely CRUD-based (create, read, update, delete)
services.
• Ask first “What does this context do?”, and then “So what data does it need to do
that?”
• When modeled as services, these capabilities become the key operations that will be
exposed across the system

Fakultas Ilmu Komputer Universitas Brawijaya

Nested bounded contexts
• At the start, you will probably identify several
coarse-grained bounded contexts.
• These bounded contexts can in turn contain further
bounded contexts.
• Example:
• The warehouse context can be decomposed into
capabilities associated with order fulfillment,
inventory management, or goods receiving.
• To the outside world, they are still making use of
business capabilities in the warehouse
• The consumer might be unaware that their
requests are being mapped transparently to two or
more separate services

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya