Overview

A microservices architecture structures a system as a set of microservices. Determining that set is a challenge — there is no well-defined algorithm for it. However, because it is a recurring task in all architectures of this type, a number of patterns have emerged to help with the division. The Decompose by Business Capability pattern is one of the primary approaches.

A good decomposition of microservices is important because it allows future changes or new requirements to affect the smallest possible set of microservices. Equally, all the advantages of microservices architectures can only be realised with a good decomposition.

Problem

How do you define the boundaries of a microservice? Decomposing by technical layers (UI, business logic, data) produces a distributed monolith. Decomposing too finely introduces unnecessary network overhead and operational complexity. A structured, business-driven approach is needed.

Solution

As the name of the pattern suggests, the idea consists of dividing microservices by business capabilities. A business capability is an activity that generates value for the business, and normally corresponds to a business object. The phases of observation, analysis, and domain modelling therefore become very important, as they help identify the business capabilities.

Example

Consider an online shop system that contains a product catalogue, order management, and customer information. The typical business objects (capabilities) that correspond to microservices, showing a clear division of responsibilities, are:

  • Product catalogue management
  • Inventory management
  • Order management
  • Delivery management
  • Customer management

An important point about this division is that the set of services and business objects should be quite stable, although each of them can change internally many times. Chris Richardson illustrates this with the example of cheque deposits: at one point done in person at bank counters, then at ATMs, and now via smartphone. In a short time, the way business actions are executed can change drastically — but the capability itself (depositing a cheque) remains.

Trade-offs

Benefits

  • Stable architecture — business capabilities are also stable
  • Enables multifunctional, autonomous development teams focused on delivering business value
  • Resulting microservices are more cohesive: well-contained, well-defined, and decoupled from other microservices

Drawbacks

  • Requires good domain knowledge to correctly identify business capabilities
  • Domain analysis, observation, and modelling become essential activities before decomposition can begin

When to Use

Apply this pattern when:

  • Designing a new microservices system and you need a stable decomposition strategy
  • The business domain is reasonably well understood, allowing capabilities to be identified
  • You want teams aligned with business units for end-to-end ownership and autonomy

Consider alternatives when:

  • The domain is complex — complement with Decompose by Subdomain for finer-grained boundaries using DDD
  • The business domain is not yet well understood — avoid premature decomposition

References