I want to understand the difference between business capability and subdomain Decomposition for mircorservices.


The subdomain decomposition corresponds to Domain-Driven Design (DDD) subdomains.

business capability

Define services corresponding to business capabilities. A business capability is a concept from business architecture modeling. It is something that a business does in order to generate value. A business capability often corresponds to a business object, e.g. Order Management Customer Management


I assume that the business capability decomposition can include a hierarchy similar to a taxonomy. That means that subdomain Decomposition is just a subset of business capability Decomposition because subdomain Decomposition can also exist without a hierarchy.


After checking two very interesting post I summaries it as follows. as the answers are quite close check them for nuanced perspective.

  1. in differentiating the two approaches the business approach groups/partitions their services by their concerns. the subdomain approach takes more a functional approach looking at similar/related topics.

  2. overly simplified business approach considers What has to be partitioned whereas subdomain How functionalities can be grouped.

  3. When decomposing into services the smaller the service the more the two approaches might drift apart. Consequently, the approaches differ more.

Overall both approaches might lead to the same result but each decomposition method values a different aspect.


Decomposition by business capability

As your quote mentions, business architecture modeling is not a software engineering discipline, it's a way for a business to understand and describe what is it that they are doing and why. A business capability is something they can do as a business to ultimately generate value for their customers (you can think of "value" roughly as of "something their customers are wiling to pay for or support").

E.g., from the example you listed, in order to sell stuff online, they have to have the capability to present products, manage orders, etc. The business has products and services they want to provide, and there are also the logistics behind that - so their business capabilities have business reasons (and possibly existing procedures) associated with them. They hire software developers to create software that enables or supports or streamlines these capabilities; software developers can in turn gain insight by developing understanding of these capabilities, the reasons behind them, and of any preexisting procedures that are already in place (see the Remarks section below).

So, some of the microservices people borrowed this concept, and they are simply recommending to investigate what these are, and to organize services around them. The decomposition criteria come from the business - it's done from the point of view of the business and the way they are thinking about their operations (although it's you, the developer (team), who has to extract and refine this information from the business). The thinking is that these capabilities will be stable enough to be a basis for relatively stable interfaces or APIs (see the Remarks section below). Whether or not you arrange these into a hierarchy/taxonomy, or a graph, or whatever, is up to you.

Decomposition by Subdomain

Subdomains are something that developers come up with, based on their understanding of the overall problem domain and its various aspects, in order to have some control over the interdependencies and the complexity of the software system. Here, the decomposition criteria are coming primarily from the developer's understanding of what the domain consists of and of how various parts/aspects of the system are going to be interconnected and interdependent, and of how the software nature of the solution comes into play.

From the DDD book:

"You may see a part of the model that can be viewed as specialized math; separate that [as a subdomain]. Your application enforces complex rules restricting state changes? Pull this out into a separate model or simple framework that lets you declare the rules."

So you see how the criteria are different. The business people may or may not see "specialized math" as a separate thing or a business capability on its own. In fact, they might not be thinking about how math comes into it at all. But to a team of software developers, it might make sense to treat that as a subdomain.

You want find a way to pull highly related things into a subdomain, and put them behind a stable abstraction (a stable interface or an API) that limits what the rest of the system knows about the internals:

"When a highly cohesive subdomain is carved out into a module, a set of objects are decoupled from the rest of the system, so there are a finite number of interrelated concepts."

This is the same motivation that is behind concepts like encapsulation, interfaces, aggregates, etc (see the Remarks section below).


Now, note that these are all conceptual. How you map these to the actual services is again up to you. It may make sense to implement most business capabilities as a single service, but maybe some capabilities are complex enough to be implemented by a group of collaborating services. A subdomain might be a cluster of services behind an API, or a single stateless service replicated for use by other services. While there is value in consistency (say, you map a capability to a single service "by default"), every once in a while you should reexamine if remaining consistent actually hurts you in a particular case. A development team should come up with some way to demarcate these architectural boundaries in the code itself, though; if they are implicit, then everyone needs to keep them in their head, which is often not going to work out.

At the time of this edit, the OP summarized the existing answers, and a part of that summary are the two points below, which I felt should be addressed.

Why is this done in the first place? What is the motivation behind this?

  1. in differentiating the two approaches the business approach groups/partitions their services by their concerns. the subdomain approach takes more a functional approach looking at similar/related topics.

I wouldn't put it quite like that, as both of those can be called "concerns" (it's one of those vague words that gets thrown around). I think the best way to think about the two is not strictly as of approaches or procedures to follow, but as of strategies for identifying potential boundaries across which the system can be decomposed in a feasible way.

You see, the challenge that we face in software engineering is that there are a lot of different ways to decompose the system (and even to think about and approach the problems/requirements) - that is, there are a lot of ways divvy up responsibilities - many of which will work reasonably well initially.

However, since the system evolves over time, due various factors, such as the team arriving to a better understanding of the domain, new requirements arising, the environment changing, etc., not all of these decompositions will keep working reasonably well - in terms of how pliable or brittle the system is when the team needs to modify it in response to these changes.

So, what you're trying to do is to gain a good enough understanding of the domain, so that you can identify aspects of it that are the most susceptible to such changes, and encapsulate them behind interfaces/APIs that are based around the aspects that are more stable in the face of change. You also want to make sure to encapsulate aspects that are closely related in the sense that they tend to change together (cohesion). Otherwise, a change will tend to have a cascading impact (won't be isolated) - which is what makes the system brittle and maintenance/evolution hard.

Now, the real world being the real world, you can't do that perfectly, but you can reduce the impact and maintain some control over this form of complexity by coming up with some initial design based on your understanding of the domain, and then iteratively refining that design on the go (which is why Agile is averse to Big Design Upfront & Waterfall, and has principles like YAGNI - it's to be able to keep refining).

Is one approach better than the other?

The two approaches are really two strategies to find candidate decompositions that align with the goal outlined above. They are not necessarily mutually exclusive.

  1. overly simplified business approach considers What has to be partitioned whereas subdomain How functionalities can be grouped.

It's not that the business approach is overly simplified, that's not what I meant to say. The business people - the domain experts - understand their domain better than anyone else, although they are not necessarily always able to express their understanding in a formal way. They may have already decomposed the problem for their own needs (in terms of how they think about their dealings and how they approach business operations), for reasons that are not obvious to you (an outsider), but that may become important as the system evolves, since they could amount to different sources of change, and thus cause you to deal with extra complexity if these are not separated out in your system.

So, decomposition by business capability might suggest ways to separate things out that you (and your team), being outsiders, didn't even think of.

On the other hand, decomposition by subdomain relies more on your own approach to modeling the domain, as well as your own insight and experience that relates to building software systems. It may help identify things that should be separated out that are not apparent in purely business-oriented modeling, but it might miss the domain subtleties embodied in capability-oriented thinking.

I don't subscribe to the idea that you should pick one and consistently stick to it, cause in the end, you're not really going to be able to identify, in every case, if a particular service (or component, or whatever) was separated out because of business capability–based decomposition or because of logical separation into subdomains. What you'll be left with is the underlying reason in terms of design and maintainability concerns mentioned above, and that's actually the important bit. How you arrived at that is helpful information, but is of secondary importance.

  • Thank you for the post. You made very good points and expanded them very well. I over simplified them in the post. Let me know if I missed an essential point.
    – A.Dumas
    Nov 5 at 14:21
  • @A.Dumas Thank you for your edit; this started out as a three-part comment under your question, but after writing comment 3/3, I decided I might as well write a full answer - adding headers has certainly made it better. I've greatly expanded the last section to address your summary. After reading Christophe's answer, I also removed the phrase "subdomains are of a larger granularity", because I realized I used the term in a slightly more specific and perhaps unjustified way that might cause some confusion; I think Christophe's usage makes more sense. Nov 5 at 19:44

Both decomposition strategies, by business capability and by subdomain, may indeed result in similar decompositions. Just look at Chris Richardson's hyperlinked examples.

The important difference is not about end-result, but about having a consistent approach allowing the different teams involved to understand the boundaries of their services/responsibilities:

  • the decomposition by business capability looks at what the company does, regardless of how exactly it does it. The service boundaries will be business activity related (i.e. organizational) and is very stable over time.
  • the decomposition by sub-domain assumes that you already have several domain models (one per sub-domain). The service boundaries will be related to the model you have, and the language of the experts, which will be influence by how the company does things. New ways of doing things could introduce new subdomains.

A very simplified example, just to illustrate the difference: take a capability like "warehouse management". In a capability based decomposition you'd have a microservice dedicated to this activity. The subdomain may initially seem to correspond to the capability and you'd think of the same decomposition. But maybe some warehouses are fully robotised, do things differently, and the experts in the field appear to use a different language with some mapping with the original subdomain. So maybe there's another subdomain. In an approach by subdomain, you could have a different microservices for the two (related but distinct) sub-domains.

The granularity decided for the decomposition has probably an even higher impact. The more granular the decomposition into capabilities or subdomains, the bigger the differences. In real life, the decomposition by business capability has rarely the same granularity than subdomains. So keep the goal in mind: in your case, what approach would allow you to best reach this goal?

  • Thank you. also your post helped understand it better. I added a keypoint to the post. by the way I thought you are Chris Richardson.
    – A.Dumas
    Nov 5 at 14:22
  • Good points. It's hard to come up with examples are absolutely clear-cut; for instance, it might be that the business thinks about "warehouse management" as a single capability, and that you've identified through your own study of the domain, or change request trends, etc., that it's better to treat it as two separate entities, but you might also come across a situation where on some level the business people had to do the same (e.g. maybe it affects their operations differently), so "warehouse management" as two separate capabilities may already be inherent in their thinking. 1/2 Nov 5 at 19:56
  • I think the two approaches are better viewed as strategies/heuristics that help you look for what the boundaries might be and so provide some guidance for how to decompose the system 2/2 Nov 5 at 19:56
  • 1
    @FilipMilovanović Thank you for the feedback. Indeed, for me warehouse management was warehouse management ans seemed really simple and straightforward until I was sensitised to the whole new world behind automated warehouses. But as you point out business capabilities might evolve as well if there are suddenly heavy business implications/benefits. Indeed in my second paragraph I tried to point out exactly what you say in 2/2: it's mainly a choice to move forward with a consistent approach without having to reopen the responsibilities discussion again and again.
    – Christophe
    Nov 5 at 23:26
  • 1
    @FilipMilovanović I did not mention it, but there are also decomposition by self-contaiend service and decomposition by teams (seeking less granular decomposition as it's sometimes pushed too far in direction of nanoservices instead of microservices). Even these different approaches could end in similar decompostion results.
    – Christophe
    Nov 5 at 23:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.