Why: the goal or problem

Imagine a recipe app where neighbors save cookbooks and buy extras. One small team needs family tags. Coordinating separate releases adds work; one shared release matters more than independent schedules.

How: work toward a solution

  1. One team ships Catalog, Library and Billing; saved Community Cookbook has no tag.
  2. Add Library tags; deploy app v2, including unchanged Billing. The app owns a shared database.
  3. Library queries Catalog in-process, then writes family. A failed lookup leaves no tag; retry after recovery.
One release unit can contain many capabilities

Illustrative example

One artifact moves together

Recipe app · one team · Community Cookbook has no family 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 family → Community Cookbook has tag family.
  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.

One release can have several replicas. A process crash affects capabilities in that instance; restoring code does not restore database writes.

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.