---
title: "Modular monoliths and microservices"
chapter: "15"
---

# Modular monoliths and microservices

Start from business boundaries and team ownership. Do not start from the number
of services.

## Modular monolith

One deployable application can contain strongly separated business modules.
This gives simple transactions, local calls, one deployment, and lower
operations cost. Spring Modulith can verify module dependencies, support
module-oriented testing, and document the structure.

## Microservices

Separate services can isolate deployment, scaling, data, failure, and team
ownership. They also introduce network failure, distributed data, versioned
contracts, tracing, deployment coordination, and higher platform cost.

## Dependency rule

Business modules depend inward on domain concepts. Web, JPA, brokers, and
vendors are adapters. Keep SAP, Salesforce, and Workday objects at the edges.

## When to extract

Extract a service when a clear business capability needs independent ownership,
lifecycle, scaling, data, compliance, or failure isolation. Measure the benefit.

## Migration

Use the strangler pattern: establish a stable contract, route one capability,
observe, reconcile data, and retire the old path. Avoid a big-bang rewrite.

## Feynman check

A modular monolith is one apartment building with strong walls. Microservices
are separate houses connected by roads. Houses offer independence but every
road can fail.