谈组件识别和划分

在SOA组件化和服务化架构下，最重要的还是前期的组件识别和划分，服务识别。对于组件划分而言最简单的目标就是要实现组件本身的搞内聚和松耦合特性，如果最终划分出来的组件之间存在大量的服务交互，那么即使使用了SOA化服务架构仍然是属于严重的紧耦合而没有达到目标。

对于组件的划分前面已经有文章专门谈到了需要从企业架构规划和分析的思路入手，基于端到端的流程建模，流程和业务功能分析，数据架构和数据分析，业务功能和数据的CRUD矩阵分析来最终确定究竟哪些功能适合最终聚合在一个业务组件里面并朝外提供服务能力。在这里其实是没有类似方程求解一样的绝对化的方法来解决识别识别和划分的问题，但是通过组件初步划分后对跨组件的业务流程协同分析和组件集成架构分析，可以反复迭代最终得到一个比较满意的组件划分。

下面就组件识别和划分的一些关键点再展开进行一些定性方法的描述。

要注意在最终组件化架构下，所有的持久化数据库表必须归属到一个特定的组件，在这里基本的原则是需要将涉及到数据新增类的操作全部划归到同一个组件，包括数据表全属性字段的变更类操作全部划归到同一个组件。而企业组件仅仅是涉及到变更这种基础数据的个别属性或状态信息。拿资产管理系统举例来说，资产新增和变更操作需要属于同一个组件，对于资产调拨，资产废弃等业务可用划归到不同的组件因为只操作到资产的个别状态属性。从业务功能和数据的CRUD矩阵分析也基本可以得到类似结论。

组件划分的粗则管控粒度弱，SOA系统内组件化的思路无法贯彻，组件划分的太细又导致大量的后续组件集成和管理的复杂度，组件划分的粒度始终都是在组件划分中最让人头疼的问题。在这里给出两个重要的思路，一个是根据业务本身的生命周期大阶段来划分组件，来采购类业务来说，可以分为大的采购计划和需求，采购策略，合同管理，采购实施等大的阶段，这个就是大的可参考组件粒度，同时让每个组件都有明确的业务含义和价值；第二个方法是多参考企业已有的职能部门划分，职能部门划分为哪些部门哪些科室本身也是考虑了业务协同中的高内聚和松耦合，完全可以作为业务组件划分的参考。再次对于大多数企业可以参考标准的业界ERP系统的模块划分方式，这些模块划分可以大致对应到组件划分可行的粒度，但是对于很多大型集团型企业而言，很多时候模块是对应到业务系统粒度。

对于组件的划分可以由粗到细逐步的划分下去，但是划分到一定的度时候就应该不再拆分。这个度涉及到三个影响因子之间的关系，一个是实际的数据库表或用技术类数据衡量，一个是业务功能点的数量，然后是划分完成后的所有组件暴露的服务总量。这三个因子间应该有一个关系，即划分的越细服务总量增加的越多，而数据对象和业务功能数量并没增加，那么超过一个阀值的时候就不应该再细分了。（这个后续我会根据实践情况来详细阐述和量化这个评估方法）。

对于一个组件是否可以拆分为两个组件，这个看起来评估会更加简单，即两个组件间交互的服务接口数量应该小于两个组件中实际逻辑方法数量的5%或者说更下。而我们在实践过程中往往看到的是两个组件超过30%以上的方法都在通过接口方式暴露，而被人为拆分为两个组件增加了系统集成的复杂度。

组件的划分和系统功能一级菜单往往也没有必然的对应关系，还是以刚才资产管理的例子来说，在系统本身的功能菜单结构上可以看到资产新增和资产统计分析是两个独立的一级菜单，但是实际情况往往是这两个大一级菜单应该划归到同一个组件能力。毕竟对于组件统计分析往往是基于底层资产存量数据进行的，存在紧耦合关系。

在基于SOA组件化架构设计下，我们一直再强调SID共享数据库和领域服务层，这个也是组件后续划分的一个基础前提。实际上当分析出大量共性能力下沉到共享领域服务层后，剩余的业务功能间往往并不再有太强的交互集成和耦合关系，而上层的业务功能组件和底层共享基础能力组件间强耦合应该是允许的一种模式。在以数据为核心的应用中这个是无法避免的一个问题。

在SOA中的业务组件一定是需要实现一个独立的业务价值单元，具备高内聚特性，即输入简单，经过一系列内部处理后形成一个简单的输出结果。如采购管理中招投标可以独立为一个组件，这个组件本身接收招投标需求，输出招投标结果，具备完整的独立自治能力，这种高自治的组件也为组件后续的灵活装配奠定了基础。组件在业务阶段重点是体现独立的业务价值，所有也叫为业务组件。组件到了分析设计阶段时候，重点则是本身需求，设计，开发测试，部署和运维管控的独立性，这些技术特征具备才可能使组件本身严格独立。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密