首页 > 架构设计 > > 6 理解业务概念和业务组件
架构的本质是研究组件及其关系。业务架构就是研究业务组件及其关系。本文介绍了业务架构设计和业务组件的基本知识。
组件化开发是软件开发中的一个常用方法。组件化开发将原有到系统级的粗粒度控制细化到了组件级别的细粒度控制,一个复杂系统的构建就是组件终集成后的一个结果。
基于组件化开发带来的好处包括:

在TOGAF并没有给出业务组件的定义,但通过了架构和构建块的定义给出了组件和构建块、架构的关系。
TOGAF中架构的定义:
1.系统在其环境中的基本概念或属性,体现在其元素、关系以及设计和演进原则中。2.组件的结构、它们之间的相互关系,以及控制其设计和演进的原则和准则。
TOGAF中构建块的定义:
构建块代表企业功能的一个(潜在可重用)组件,可以与其他构建块结合以提供架构和解决方案。

TOGAF术语中,构建块和组件的含义是一致的。构建块在不同粒度上抽象了企业的各种概念(元素),包括了业务概念、应用概念、数据概念和技术概念。
借用构建块的定义,我们也可以给出TOGAF中业务组件的定义:业务组件是代表企业业务功能的一个(潜在可重用)模块。
TOGAF中组件的概念代表了我们对组件的理解:
先来看一下,CBM组件化建模中业务组件的定义:
业务组件(Business Component,BC)一个可以独立运行的构建企业的系统或功能模块。通俗来说,业务组件就是对达成特定目标,需要完成的一组紧密关联的工作事项的合集。
CBM中的业务组件实际上对应的是TOGAF其中一个业务组件:能力组件。CBM组件模型本质上是企业能力模型。

能力这个组件是TOGAF中抽象度比较高的一个组件,笔者认为TOGAF是缺乏能力建模方法的,CBM组件化建模方法补齐了这个不足。
业务架构设计包括两种思路:采用自顶向下,也就是基于企业架构的方法论;也可以自底向上,基于遗留系统分析和重构。如果我们采用是自顶向下的分析过程,我们我可以把CBM建模的输出(企业能力视图),作为我们流程建模、服务建模和数据建模的输入。
需要说明的是CBM建模自身也可能采用自底向下的分析过程,如果是这样,企业能力视图就是中间产物,而非业务建模的起点,后续将会详细说明这一点。
架构的本质是研究组件及组件的关系。业务架构设计实际上包含两个过程,
1)识别业务概念及其映射的业务组件;
2)构建组件之间的关系。

这里我们需要明确业务概念和业务组件的区别:业务概念是对业务比较重要的人、事、物,例如客户、订单、渠道等,比较口语化。业务组件是业务建模中用到的模块,例如角色、业务对象、业务接口等,比较专业化。另外,业务组件对业务概念在不同粒度上进行了抽象。
理论上,你当然可以直接用业务概念直接进行建模,这没有什么不妥之处。但业务组件的好处在于标准化,这有助于后续的组件复用以及团队沟通。
例如以下是我们常用的一些业务概念:
...
下列是我们常用的业务组件:
...

业务概念抽象为业务组件后,名称可能会发生变化,也可能不变化:
名称相同:
名称不相同:
业务架构师件事就是要弄清楚业务的基本概念和底层逻辑,而不是建模。从这个意义上,商业模式应该是业务架构师的堂课。
业务架构可以看做由多个高内聚、低耦合的业务组件构成。业务组件的划分方法和粒度和我们建模的视图有关。
由于业务包含的概念比较多,所以业务架构不可能用一张图来表达,这是业务架构很重要的一个特点。业务架构建模步是了解需求方意图,也就是你想要表达什么?这个意图就是需求方的关注点,也就是视角。视角决定了需要呈现的内容,也就是视图。
业务组件的划分需要和业务架构视视图对应,可以将业务架构图中的每个业务模块识别和定义为一个业务组件,也可以根据高内聚、低耦合准则将多个业务模块合并为一个业务组件。
如果需求方需要一张企业顶层的业务功能规划图,可以采用CBM组件化模型方法,需要的是能力组件。

如果需要的是细粒度的业务功能图,可以使用业务功能、业务服务组件。

如果需要一张组织结构图,可以使用业务角色组件。

如果需要分析业务服务和业务渠道的关系,可以使用业务接口、业务功能和业务服务这些组件。

End
相关阅读:
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70000523/viewspace-3155552/ ,如需转载,请注明出处,否则将追究法律责任。