Decompose microservices: Business capability vs Domain

Question

As I read, there are two patterns to define one microservice, by business capability and by subdomain. But I still find it very ambiguous. I get confused how these two patterns differentiate from each other. Both of them revolve around activities involving an area of business logic. All of components in each service are small enough to get packaged with each other without affecting other services. Could anyone please give me a further explanation about these two?

Backlash

The reason this is ambiguous is that the same wording has been copy/pasted from one article to the other and a few key words changed. Ultimately, domain and capability are subjective terms. – Suburbia

Agree. It depends on context. Subdomain could also refer to business domain. – Stenotype

I'm voting to close this question as off-topic because it's a better fit for softwareengineering.stackexchange.com – Sheff

Answer 1

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.

Giotto

thanks for the wonderful explaination, but I am still confused over these patterns. For me, it looks like Domain-driven is a subpart or next step after decomposition by business capabilities. i.e one the Business verticals are identified one need to apply the Domain-driven concept to define the entities and their responsibilities within an bussiness vertical/capabalities – Vaporimeter

Analysis of entities is "tactical DDD", an approach for designing the 'internals' of a service. This question is more about 'strategic' design; the discovery of high level 'boundaries'. e.g. the decomposition of an overall problem space into domains and/or business capabilities and then to microservices. The challenge here is that the terms are not precisely defined. My answer above is not authoritative, it's just one way of thinking that has helped me. For an academic overview of Business Capabilities, this paper is good: liacs.leidenuniv.nl/~plaata1/Offerman2017_SLR.pdf – Giotto

Answer 2

Business Capabilities do not reflect 1-to-1 the organisational structure. The represent what the business does (what capabilities it has) without specifying how they will be implemented. The organisational structure is part of the "how" / implementation.

If your business capability map is structured according to your organisational structure, then this should be evaluated more closely, unless of course, you create the business capability map first and then changed the organisational structure accordingly.

I've dealt with both Domains and Business Capabilities. They are essentially the same, depending on the level at which you are working.

Letourneau