Decompose by Subdomain (DDD)

Use Domain-Driven Design bounded contexts to create services with their own language and model.

DDD

Detailed Description

A bounded context defines where a model and vocabulary are valid. In microservices, that boundary often becomes a service boundary.

This avoids one giant shared model that means different things to different teams.

Visual Diagram

DDD Subdomains
  Core Domain     → OrderService    (competitive edge)
  Supporting      → InventoryService (needed but not core)
  Generic         → AuthService     (buy/use off-shelf)

Each has its own model & language

Tradeoffs

Pros

Clear models, bounded contexts, rich domain language

Cons

Requires domain modeling maturity

Examples: DDD by Eric Evans, Vaughn Vernon