对组件化开发的再思考

还是先说明基于组件化开发带来的优势，首先原有到系统级的粗粒度控制细化到了到组件级别的细粒度控制，一个复杂系统的构建就是组件最终进行集成后的一个结果。每个组件都自己独立的版本，组件可以独立编译，独立打包和部署。其次产品组件化后可以真正实现完整意义上的按组件进行产品配置和销售，用户可以选择购买哪些组件，组件之间可以灵活的进行组装。另外包括我们说的配置管理，开发，测试，打包，发布完全控制到组件层面，带来额外其它很多好处，如我们常说的如果一个组件进行小版本升级，如果提供给外部的接口没有任何变动，其它组件完全可以不用做任何测试等。

组件化开发思路在SOA之前已经有成熟的组件化开发方法，只是在SOA出现后，SOA咨询，需求分析，设计实现方法论进一步融入到组件化开发中。各种底层基础技术框架的发展和完善，为组件化开发提供了根据完整的支持，推动组件化开发的发展，特别是在B/S架构下的组件化开发。回到软件生命周期，我们再来阐述下组件化开发的核心思路和逻辑。

业务建模和业务组件阶段

流程驱动IT以及SOA思想的进一步融合，再次改变原有的组件开发重点关注技术组件层面的问题。业务建模阶段重点包括了业务架构和数据架构，其导入仍然是端到端流程分析为主线导入。业务架构分析重点就是形成业务组件，也可以叫业务模块。

在这里重点还是业务组件的形成，要知道业务组件来源于流程分析和流程分解，业务组件本身就是高度内聚的多个业务功能的一个集合，业务组件之间本身就是松耦合，业务组件通过交互和集成可以完成一个更大的端到端流程。业务组件的识别仍然回归传统的流程分析加面向结构下面的CRUD矩阵分析等方法来分析高内聚性。矩阵分析包括了业务功能和业务数据之间的CRUD关系，也包括了业务功能和业务功能之间本身的关联和依赖性分析。

对于粗粒度的数据建模我们把它划归到业务建模阶段，该阶段的数据建模偏概念模型，后续在设计阶段再转化到物理模型和数据实体组件。同时该阶段的数据建模需要梳理出业务和流程中核心的基础主数据和核心业务单据，分析业务单据关联映射关系，协助前面谈到的CRUD矩阵分析。

在这个阶段最终需要输出的涉及到组件层面的产出物包括软件系统的业务组件，每个业务组件包含的业务功能或叫业务用例。整个业务系统中的业务实体，业务实体关系图等。

软件需求阶段

在这个阶段不做详细的说明，但是我们仍然需要理顺整个关系，即首先形成业务组件，业务组件是大的业务模块。业务组件下面有业务用例，这里的业务用例通过进一步的需求分析和开发，将业务用例转换为系统用例，然后对每一个系统用例进行详细的描述。业务流程-》业务组件-》系统用例是一个从顶向下，逐层展开的一个分析过程。

在传统的用例建模中，我们没太关注用例之间的交互，而将其延后到设计和实现阶段去完成。现在来看该工作需要提前，即从全系统来看，首先完成对业务组件之间交互的描述，对交互点和交互场景进行详细说明。在细化进入到一个业务组件内部后，需要对系统用例之间的相互调用进行描述。

对于数据层面则在软件需求阶段进一步细化，从概念模型阶段过渡到逻辑模型阶段，进一步细化业务功能为系统操作，分析系统操作和数据对象之间的关系。

系统建模和技术组件阶段

这个阶段即传统的架构设计阶段，我们仍然是组件化开发的一个重点，这里的系统建模和架构设计重点都变化为功能性架构。但是前面业务建模阶段已经有前期的积累。如果是业务建模阶段是系统分析的话，那么系统建模阶段是系统设计。

系统建模阶段第一个重点是要实现从业务组件到技术组件的细化，在SOA中我们谈到业务组件，服务组件和技术组件。在这里我们只谈业务组件和技术组件，并弱化服务组件的概念。首先进入了架构分层后，一个业务组件可能需要拆分为多个技术组件，包括数据层组件，逻辑层组件，UI层组件，数据实体组件等。其次在该阶段我们会引入很多的纯技术层面的组件，这些技术层面组件和业务完全无关而和平台非功能性架构有关，如安全，异常，日志等相关组件等。

业务组件本身符合高内聚性，转换到技术组件后仍然需要符合高内聚性，技术组件之间其一不允许出现相互交叉调用，其二整个调用关系应该是从上层往下层调用。纵向看是UI组件->逻辑层组件->数据层组件调用关系，而横向看则是同层之间的各个技术组件之间存在相互调用关系。按照组件最大化复用原则，优先考虑UI组件复用，其次考虑逻辑层复用，最后才考虑数据层复用。

根据前面分析可以很明显的看到在系统建模阶段关于组件分析和设计的几个重点内容。其一是业务组件转换为技术组件，并按层分解。其二是根据业务交互，用例交互分析组件之间的调用关系，这些调用关系就是组件间的接口，通过业务和流程分析的方法来找到接口，转到相关组件的接口设计上，组件之间的调用只能通过接口，组件内部完全黑盒。其三是数据建模和设计，将前面数据建模分析内容转换为数据实体组件，数据实体组件只含数据实体，实现控制类和实体类的分离。这样数据实体类容易变化为下层可以被多个逻辑层技术组件引用的组件。

在这个阶段在传统的架构设计文档上，可以看到需要输出的内容包括了业务组件->技术组件的对应清单，组件调用关系和依赖关系图，组件接口设计文档和接口清单，可复用组件抽取和分析，组件包视图和部署视图，整个应用系统的组件化后的产品结构视图和配置项清单等。

实现阶段

实现阶段我们关注的问题即一个技术平台或框架支持组件化开发，测试和部署。传统的BS架构开发我们比较难以解决的问题是UI层内容的独立打包和部署，而现在类似T5框架可以做到更好的支持。T5框架再加上OSGI可以比较好的实现我们需要的组件式开发，动态发布部署，组件热插拔等基本需求。

可以单独对组件进行自动化的单元测试，当某个组件有变化的时候，可以单独对变化的组件进行版本升级，单独对变化组件进行部署。整个产品的版本由应用系统管理到里面的每个组件，这些都将是发生变化的点。