blocks|key|1477905|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<h1>Decomposition by business capability</h1>
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 &quot;value&quot; roughly as of &quot;something their customers are wiling to pay for or support&quot;).
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.
<h1>Decomposition by Subdomain</h1>
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 <a href="https://rads.stackoverflow.com/amzn/click/com/0321125215" rel="nofollow noreferrer" rel="nofollow noreferrer">DDD book</a>:
<blockquote>
&quot;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.&quot;
</blockquote>
So you see how the criteria are different. The business people may or may not see &quot;specialized math&quot; 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:
<blockquote>
&quot;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.&quot;
</blockquote>
This is the same motivation that is behind concepts like encapsulation, interfaces, aggregates, etc (see the Remarks section below).
<h1>Remarks</h1>
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 &quot;by default&quot;), 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?
<blockquote>
<ol>
<li>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.</li>
</ol>
</blockquote>
I wouldn't put it quite like that, as both of those can be called &quot;concerns&quot; (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 &amp; 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.
<blockquote>
<ol start="2">
<li>overly simplified business approach considers What has to be partitioned whereas subdomain How functionalities can be grouped.</li>
</ol>
</blockquote>
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.

I want to understand the difference between business capability and subdomain Decomposition for mircorservices.
<h2>subdomain</h2>
The subdomain decomposition corresponds to Domain-Driven Design (DDD) subdomains.
<h2>business capability</h2>
<blockquote>
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
</blockquote>
<h4>Assumption</h4>
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.
<h2>Summary</h2>
After checking two very interesting post I summaries it as follows. as the answers are quite close check them for nuanced perspective.
<ol>
<li>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.
</li>
<li>overly simplified business approach considers What has to be partitioned whereas subdomain How functionalities can be grouped.
</li>
<li>When decomposing into services the smaller the service the more the two approaches might drift apart. Consequently, the approaches differ more.
</li>
</ol>
Overall both approaches might lead to the same result but each decomposition method values a different aspect.

What is the difference between business capability and subdomain Decomposition in microservices?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我想了解镜像服务的业务能力和子域分解之间的区别。子域子域分解对应于域驱动设计(DDD)子域.业务能力定义与业务功能相对应的服务。业务能力是业务体系结构建模中的一个概念。这是一个企业为了创造价值而做的事情。业务能力通常对应于业务对象，例如订单管理客户管理假设我假设业务能力分解可以包含类似于分类法的层次结构。这意味着子域分解只是业务能力分解的一个子集，因为子域分解也可以在没有层次结构的情况下存在。摘要

问在微服务中，业务能力和子域分解之间有什么区别？
EN

子域

业务能力

假设

摘要

回答 1

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在微服务中，业务能力和子域分解之间有什么区别？EN

子域