前期《组件化业务模型（component business model, CBM）》（链接）已经阐述了CBM对于企业专业整合、灵活运营、基于SOA构建信息系统的作用。 CBM 由业务组件描述和组成。本文主要介绍业务组件的定义、功能、设计和验证方法。
1. 业务组件定义
业务组件（BC）的定义是：构建企业能够独立运行的系统或功能模块。通俗地说，业务组件是为了实现特定目标而需要完成的密切相关的工作项的集合。
2. 业务组件的作用
业务组件的作用是通过组件化企业功能，从专业分工的角度构建企业业务能力网络，从而实现企业的专业化和柔性化。这部分内容已在《组件化业务模型（component business model, CBM）》（链接）中进行了说明，本文不再重复。
业务组件还可以提供后续的基于SOA的服务目录列表。虽然业务组件定义期间服务还没有细化为服务，但业务组件组件化后，我们可以通过流程进一步分析业务组件之间的关系和交互。确定业务组件之间必须存在的接口和数据交互，以完成完整的端到端流程，而这些交互是识别服务的关键点。业务组件不是孤立的，而是组装在一起完成流程的集成。为了实现这个目标，业务组件必须暴露相应的服务能力，也就是我们所说的组件本身的服务能力。
3. 业务组件五要素
业务组件是组件化业务模型（CBM）的核心。两者的关系如图1所示。
图1 CBM与BC的关系
业务组件由五个元素组成（参见图2）：
目标/目的：为什么存在、创造什么价值以及如何衡量它；活动：定期进行哪些简单、有凝聚力的活动；资源：需要哪些知识、资产和人力资源；治理：如何管理活动和资源；服务：从其他组件获取什么内容以及向其他组件提供什么内容。图2 业务组件五要素
3、业务组件特点
业务组件具有以下特点：
业务组件有自己的输入/输出，在企业内承担特定的职责，并对外提供服务；业务组件是独特的、不重复的构建块，由一系列密切相关的活动组成，并且可以独立运行；企业的所有业务活动只能属于某个组件，组件之间通过调用服务进行协作和交互；业务组件具有高内聚、低耦合的特点。所谓耦合是指两个组件。其中一项的变化会影响另一项的相应变化。所谓凝聚力，就是独立、单一、界限清晰。业务组件彼此隔离。如果更改其中一项，界面保持不变，不影响系统。业务组件高内聚低耦合是指业务组件通过低耦合的方式联系起来，具有灵活、响应快、可用性强的特点；其次，业务组件内部的活动具有较高的凝聚力，能够对外提供效率高、优质的服务。因此，企业管理的目标是降低业务耦合（解耦），提高企业凝聚力（专业化）。耦合度分级如图3所示。 图3 耦合度分级
4、业务组件划分原则
业务组件是一系列不可分割的业务活动，那么业务组件如何划分呢？还是要从业务组件的定义和特点出发，从业务组件是企业专门的功能模块的本质出发，从业务组件高内聚、低耦合的特点出发，然后综合考虑以下几点因素：
类似的商业活动；使用相似的数据；有共同的加工程序；共同的业务目标；密切相关的组织单元共享组件，企业可以显着提高运营效率，增强差异化竞争优势。业务组件的划分需要深入了解业务之间的关系，根据企业战略、管理和执行的要求进行分类和划分。这就需要有良好的业务分类能力，并考虑业务之间的数据流动和共享。
5、业务组件的粒度
业务组件的粒度用来表示业务所包含的业务组件的大小。它是组织管理粒度的体现，是达成共识的范式。粒度过大，功能复杂，灵活性低，升级困难（独立升级能力往往是决定业务组件范围的重要因素），难以实现复用；粒度太小，业务组件数量较多，导致业务组件之间交互增多，导致管理成本增加，性能变差。因此，找到合适的业务组件粒度非常重要。
首先要注意的是，对于业务组件的粒度，没有硬性且快速的指导方针，因为它不是一件困难或可衡量的事情。一般来说，业务组件的粒度应该更多地从业务直接实现的业务目标层面来考虑。业务组件的精简代表着管理能力的重点、灵活性的提高、复杂性的降低。我们可以从以下几个角度来确定业务组件的粒度：
业务特征：不同的业务特征导致不同的业务粒度。例如，在行政管理中，各个业务事项相对独立，业务事项之间松耦合明显，业务组件可能较多；抽象层次：不同的抽象层次导致不同的业务粒度。如总部级、部门级；避免陷入根据日常业务的频率、耗时、工作量等来评估粒度大小的陷阱。发生频繁、耗时较长的业务不能简单地定义为一级组件。组件的大小应根据此类业务的目的和价值进行评估；对于几个始终相互配合的业务，且任何业务不被除这些业务之外的其他业务调用的情况，建议将这些业务合并为一个组件。一个业务组件的输出必须被多个业务组件使用。如果一对一使用，则意味着组件可以合并。 6、业务组件验证方法
业务场景交叉分析方法业务场景交叉分析方法（见图4）类似于软件测试的白盒测试，即通过“测试用例”（流程场景）来验证软件的外部流程和内部业务活动。组件，并验证组件的正确性。
对于业务组件的CBM图，首先同一业务域下的业务组件应该能够串联。其次，不同业务域下组件之间的交互关系应该体现在同一层面上，即战略层面不同业务域之间的交互应该体现在战略层面和管理层面不同业务域之间的交互上。体现在管理层，执行层不同业务域之间的交互也应该体现在执行层。交互过程中不应该存在斜杠关系。
图4 业务场景交叉法
业务组件依赖分析方法业务组件依赖分析类似于软件测试的黑盒测试，即不关心内部组件，而是通过验证外部接口关系分析（组件输入、输出和支持）。
图5 业务组件依赖分析图
通过连接业务组件的输入和输出，可以分析业务组件在功能层面是否准确。总体而言，战略、管理和执行层面的业务组件在连通性方面具有图6的特征。
图6 业务组件不同功能级别的特点
