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.