Why: the goal or problem

A small app needs manageable releases. Coordinating separate services can cost more than the problem warrants.

How: work toward a solution

  1. Fictional app v1: one team deploys Catalog, Library and Billing together; A17 has no tag.
  2. Add tag support in Library; deploy app v2. Billing behavior stays unchanged, but ships in the same artifact. The app owns a shared database.
  3. Library calls Catalog in-process, then writes travel. A Catalog error before writing leaves no tag; retry after recovery.
One release unit can contain many capabilities

Illustrative example

One artifact moves together

Reading app · one team · A17 has no tag

Change: add a Library tag; Billing behavior stays unchanged.

Deployment unit · 1

App v1 → App v2

Build and release the whole server application

  1. Catalog

    Behavior unchanged

  2. Library

    Tag feature added

  3. Billing

    Behavior unchanged

Library → Catalog · In-process call

Capability boxes leave internal modularity unspecified.

Shared database · owner: application

Catalog / Library / Billing

Library writes the tag after Catalog lookup succeeds.

  1. Lookup succeeds → write travel → A17 has tag travel.
  2. Lookup fails before writing → no tag. Report failure; retry after recovery.

Replicas are copies of the same artifact, not separate services. A process crash can affect all capabilities in that replica.

Ownership boxes describe access rules, not database-machine counts.

What: the concept

A monolith deploys its server application as one unit. Replicas of that artifact remain a monolith; internal modules are allowed. Lewis and Fowler

Releases and process failures are shared. Add explicit modules as boundaries matter.