MICROSERVICE

ARCHITECTURE
Komunikasi Proses Bisnis pada Microservice

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

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya

Communication in Terms of Business Concepts

• The changes we implement to our system are often about changes

the business wants to make to how the system behaves.
• We are changing functionality —capabilities— that are exposed to
our customers.
• If our systems are decomposed along the bounded contexts that
represent our domain, the changes we want to make 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.

Fakultas Ilmu Komputer Universitas Brawijaya

Communication in Terms of Business Concepts

• Think of the communication

between 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.
• It can be useful to think of forms
being sent between these
microservices, much as forms are
sent around an organization.

Fakultas Ilmu Komputer Universitas Brawijaya

The Technical Boundary
Case Study
• Got client from a company in California.
• helping the company adopt some cleaner code
practices and move more toward automated testing
• The team, and system, had grown
• The system had taken on more and more features,
and more and more users.
• The organization decided to increase the capacity of
the team by having a new group of developers
based in Brazil take on some of the work.
• The system got split up:
• Front half of the application being essentially stateless,
implementing the public-facing website
• Back half of the system was simply a remote procedure
call (RPC) interface over a data store.
imagine you’d taken a repository layer in your codebase and
made this a separate service.

Fakultas Ilmu Komputer Universitas Brawijaya

Repository Layer

Fakultas Ilmu Komputer Universitas Brawijaya

Repository Layer (Cont.)

Fakultas Ilmu Komputer Universitas Brawijaya

Case study
(Cont.)
• Changes frequently had to be made
to both services.
• Both services spoke in terms of low-
level, RPC-style method calls
• The service interface was also very
chatty too, resulting in performance
issues.
• This resulted in the need for
elaborate RPC-batching mechanisms.
Joking aside, it is an onion architecture à it had lots of layers
and possibly made use cry when we had to cut through it.
Fakultas Ilmu Komputer Universitas Brawijaya
The Technical Boundary
(Cont.)
• Now on the face of it, the idea of splitting the previously monolithic system
along geographical/organizational lines makes perfect sense
• However, rather 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.
• Making decisions to model service boundaries along technical seams isn’t
always wrong à make lots of sense when an organization is looking to
achieve certain performance objectives
• It should be our secondary driver for finding these seams. The primary one
should always be the bounded contexts that represent our domain.

Fakultas Ilmu Komputer Universitas Brawijaya

Fakultas Ilmu Komputer Universitas Brawijaya