Service decomposition

Explore Service decomposition.

3 field notes

Service decomposition

Independent releases introduce remote failure cases

Planning & architecture / Service decomposition01

Microservices

Release capability services independently.

Open field note

Internal contracts, shared release

Planning & architecture / Service decomposition02

Modular monolith

Keep module ownership inside one release unit.

Open field note

One release unit can contain many capabilities

Planning & architecture / Service decomposition03

Monolith

Release the server application as one unit.

Open field note

Comparison within this category
Concept	Features	Advantages	Limitations	Suitable situations	Combination conditions
Microservices	Independently deployable capability services	Library can release without rebuilding Billing	Network failures and data coordination	Stable boundaries and independent release needs	Can coexist with a modular monolith
Modular monolith	Explicit module APIs within one deployment	Library changes stay behind its API	Boundaries need enforcement; releases stay shared	Clear ownership without remote calls	Can use clean or hexagonal module internals
Monolith	One server-side release unit	One release pipeline for a small team	Shared release and process failure boundaries	Closely related capabilities with one team	Can contain layers and explicit modules