本文主要是介绍领域驱动设计--多维度规划业务架构(三)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
领域驱动设计的社区主流声音是划分问题空间（Problem Space）与解空间（Solution Space）。整个问题空间实际上就是团队开发的目标系统对应的领域，这实际上也是业务架构要描述的目标。领域驱动设计解决大规模问题空间的方法或模式是引入子领域（Subdomain）。
根据价值高低的不同，子领域分为核心子领域、支撑子领域和通用子领域。若将其引入到业务架构，似乎可以根据价值高低建立不同的服务层，例如：
-
核心子领域：产品服务层，体现为子领域专用的产品服务
-
支撑子领域：能力服务层，体现为跨子领域复用的能力服务
-
通用子领域：基础服务层，体现为与领域无关的基础服务
不同的层次代表了复用的粒度和水平。基础服务层因为与领域无关，它复用的范围更广泛，对应为业务架构中的支撑业务（支撑部门提供的职能），如财务体系、人力资源体系、行政体系、采购体系等。原则上，任何企业都需要这些支撑业务，而与企业从事的领域方向无关。引入领域驱动设计的概念，我将其纳入到通用子领域的范畴。
企业核心业务对应为核心子领域，对外公开为一个个相对完整的产品服务。一个产品服务可以认为对应一个核心子领域。在识别核心子领域（产品服务）的过程中，我们需要遵循能力复用的原则，尝试去寻找那些可以跨子领域复用的业务能力，然后自上而下进行沉淀，从而形成映射支撑子领域的能力服务层。
以上内容，我称之为领域维度的业务架构规划，如下图所示：
从商业维度，Gartner定义了Pace-Layered Architecture，如下图所示：
它按照变化速率将企业应用分为了三个层次：
-
创新型系统，SoI（System of Innovation)
-
差异型系统，SoD（System of Difference）
-
记录型系统，SoR（System of Record）
Gartner分别从变化频率、生命周期、规划远景、治理模型、利益相关者、资金和架构七个角度阐述了各个层次的特征与属性。
商业维度的划分依据可以对领域维度的业务架构规划进行指导与调整，当然，它们之间也存在若有若无的映射关系，形成了如下图所示的商业维度的业务架构规划：
子领域的划分在业务架构规划的每个层次形成各自的子领域，它是分解问题空间的最高抽象层次（依据分解粒度），我将其称之为“业务领域”。在业务领域之下，是由业务服务组成的业务组件。
这里的业务服务与业务组件是我自己提出的定义，并非业务架构知识体系中的概念：名称相同，含义并不完全相同。
业务架构的业务服务“表示显式定义的暴露业务行为，代表了用于实现组织内外客户需求的服务，并处理主体与主体之间、主体和客体之间的连接物”。这一定义没有清晰地说明业务服务到底是什么，也没有明确划分依据，无法确定其设计粒度。我在《解构领域驱动设计》一书中明确指出了业务服务的定义，即它是“角色主动向目标系统发起服务请求，完成一次完整的功能交互，体现了服务价值的业务行为”，如下图所示：
基于这一定义，可以确定业务服务的粒度与层次。
在业务架构知识体系中，IBM提出了业务组件模型，“采用目标、资源、活动、治理、服务5个标准属性来表达能力以及能力之间的关系”。我所定义的业务组件其本质实际是业务角度的限界上下文。
通常认为，限界上下文属于解空间的DDD模式，但在识别限界上下文时，实际上首先是从业务角度对基本的业务单元（即业务服务）进行归类与归纳。在规划业务架构时，如果我们仅将限界上下文视为领域模型的知识语境边界，不去考虑技术实现的内容，那么，将其映射为业务架构的业务组件也未尝不可。
由此，就形成了业务领域-业务组件-业务服务的分析粒度层次，我将其称之为分析维度的业务架构规划，它是业务架构映射为应用架构的基础，使得整个企业架构具备了落地的可能性。这一维度的业务架构规划如下图所示：
领域维度的判断依据是领域价值的高低，商业维度的主要判断依据是变化速率和规划愿景，它们共同映射为不同服务层次进行规划的业务架构，最后从分析维度对每个服务层次的业务逻辑进行切分与细化，为业务架构映射为应用架构提供落地实现的基础。
❀❀❀
☼ 素履之往：2021年6月15日晚，摄于成都太古里。
这篇关于领域驱动设计--多维度规划业务架构(三)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
