Decompose microservices: Business capability vs Domain

The commenters are right - there are some subjective definitions at play here. But there are some principles and concepts that can help reason about the different approaches.

Conway's Law

It's not strictly the original definition, but I think the distinction can be better understood with reference to Conway's Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

The Inverse Conway Manouvre

Following from that thinking, the Inverse Conway Maneuver evolved:

The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture.

The Inverse Conway Maneuver is an attempt to structure your organisation to harness Conway's Law to achieve a better system design.

Decomposition By Business Capability

With an understanding of these concepts, we can consider decomposition by Business Capability to be guiding the system design according to the way the business is structured. This echos Conway's law.

The pro of this approach is it helps to ensure alignment between development teams and business structural units. The con is it may bake business inefficiencies that arose before an automated system was considered, into the design of your system.

Decomposition By Domain

Domain Driven Design (DDD) provides a suite of tools and methodologies to reason about the underlying domain at hand, to reflect the best available understanding of the domain in the software design and to evolve the software design as understanding of the domain grows and changes. DDD Strategic Patterns guide the creation of a Context Map which can form the foundation of your microservices decomposition.

From this, we can consider decomposition by Domain to be guiding the system design according to an analysis of the processes and information flows .

The pro of this approach is that it can lead to a system design that closely models the reality of what is happening (or needs to happen). Hopefully the business structure already aligns with this - but where it doesn't, it can reveal inefficiencies in the existing business organisational structure.

If you have influence over the organisational structure, this can be a foundation for utilising the Inverse Conway Maneuver and to allow you to evolve the software, the dev teams and the business units to achieve alignment.

If you don't, you may end up introducing friction points where the system design becomes misaligned with the business capabilities.

Conclusion

The reality is, neither approach is mutually exclusive - you will probably end up with a compromise that attempts to balance alignment with business capabilities as they are already understood and problem domains as they are revealed through a DDD process.