Overview

The Decompose by Subdomain pattern is an alternative to Decompose by Business Capability. It applies Domain-Driven Design (DDD) principles to decompose a system into microservices by identifying subdomains — multiple domain models, each with a different scope and objective.

Problem

In a traditional modelling approach, a single model is normally created to describe the entire domain, making it unnecessarily complex. The difficulty with this approach is trying to get different parts of the business to agree on a single model, which can be too complex for some parts' requirements. How do you decompose a system into microservices when the domain is large and complex?

Solution

Domain-Driven Design solves this problem by defining multiple domain models — subdomains — each with different scopes and objectives, allowing different parts of the business to adapt the domain model to their requirements. This gives rise to two very important DDD concepts in the context of microservices architectures:

  • Subdomains — equivalent to microservices
  • Bounded contexts — the boundaries of the microservices

The application of the Decompose by Subdomain pattern consists of dividing these multiple domains, which in practice corresponds to decomposing the system into microservices with well-defined boundaries — an alternative to Decompose by Business Capability.

Example

Using the same online shop system as an example, the domain of the online shop must be divided into subdomains, where each subdomain corresponds to a microservice. Typical subdomains might include: Products, Categories, Orders, Inventory, Customers, Payments, and Deliveries — each becoming a microservice with well-defined bounded contexts separating their concerns.

Trade-offs

Benefits

  • Same advantages as Decompose by Business Capability
  • Each team adapts their domain model to their own requirements — no forced consensus on a single global model
  • Bounded contexts enforce clear service boundaries that prevent leakage of implementation details

Drawbacks

  • Architecture stability depends on the stability of the subdomains (unlike business capabilities, which tend to be more stable)
  • Requires good domain knowledge to correctly identify and bound each subdomain

When to Use

Apply this pattern when:

  • The domain is large and complex, requiring multiple distinct models with different scopes
  • You are following a DDD approach and have identified bounded contexts
  • Different parts of the business have conflicting views of the same domain concept

Consider alternatives when:

  • The domain is simpler — Decompose by Business Capability may be sufficient
  • The subdomains are not yet well understood — premature decomposition leads to incorrect boundaries that are costly to change

References