作者：人月神话，新浪博客同名

今天介绍下组件化开发方面的内容，在前面我讲解微服务的时候就已经谈到，实际上微服务本身就是传统的业务系统组件化开发的一个升级。懂得基础的组件化开发和技术架构设计是也是过渡到当前主流的微服务架构思想的基础。

组件化开发概述

在这里先介绍和说明下基于组件化开发带来的优势。

首先，原有到系统级的粗粒度控制细化到了组件级别的细粒度控制，一个复杂系统的构建就是组件最终集成后的一个结果。每个组件都自己独立的版本，组件可以独立编译、独立打包和部署；

其次，产品组件化后可以真正实现完整意义上的按组件进行产品配置和销售，用户可以选择购买哪些组件，组件之间可以灵活的进行组装。另外，包括诸如配置管理、开发、测试、打包、发布完全控制到组件层面，会带来其它很多好处，如果一个组件进行小版本升级，提供给外部的接口没有任何变动，其它组件完全可以不用做任何测试。

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

回到软件生命周期，我们再来阐述下组件化开发的核心思路和逻辑。

业务建模和业务组件阶段

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

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

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

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

软件需求阶段

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

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

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

系统建模和技术组件阶段

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

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

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

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

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

实现阶段

实现阶段我们关注的问题是一个技术平台或框架支持组件化开发、测试和部署。传统的B/S架构开发我们比较难以解决的问题是UI层内容的独立打包和部署，而当前在新的微服务架构和前后端分离开发框架下，已经可以完全做到前端和后端单独打包和部署。

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

业务架构设计

业务架构设计是定义和识别业务组件的基础。对于业务架构的设计需要遵循企业架构方法论中业务流程分析思路，借鉴IBM的CBM组件化的业务模型建模思路。

业务架构是一个纯粹意义上的业务概念，只关心具体的业务域和业务功能。业务架构可以看做由多个高内聚、低耦合的业务组件构成，因此在业务架构完成后基本就确定了业务组件的划分方法和粒度等问题。

业务组件的划分需要和业务架构图对应，可以将业务架构图中的每个业务模块识别和定义为一个业务组件，也可以根据高内聚、低耦合准则将多个业务模块合并为一个业务组件。以采购管理业务域为例，经过前期的流程分析和业务交互矩阵分析，得出如下的业务架构图：

进一步基于业务高内聚的思想，可以将采购管理业务划分为招投标管理、采购管理、基础数据管理、采购绩效分析等多个业务组件并指导后续的组件设计和开发。

比如我们基于价值链已经看到供应链跨越流程，那么我们可以对供应链流程进行梳理。

梳理完后你会发现，输出的职能带流程图中的大阶段刚好就是你业务架构里面的业务域或业务单元。或者流程图中的业务活动刚好就是你业务架构分解到最底层的业务功能模块。

即当我们流程分析到最底层后，我们就可以抽象输出一个最底层的业务架构图。比如对应供应链和采购管理，我们可以输出到最底层的业务架构图或业务组件图。

逻辑架构设计

对于应用层的逻辑架构仍然参考平台+服务+应用分层的思路，对于新平台架构下应用必须结合平台层和服务能力才能组装成为一个传统的完整应用。对于应用层而言，其中仍然分为数据层、业务逻辑层和展现层的三层架构模式：

数据层

数据层主要包括了对于主数据等共享数据的访问和读取，也包括了对业务组件模块自己私有数据的CRUD操作。数据层可以直接调用DaaS服务层能力操作底层数据库，也可以直接调用封装后的领域数据服务能力查询和访问数据。

业务逻辑层

业务逻辑层和传统业务逻辑层最大的区别是体现了SOA服务化的思想。即对于业务流程和功能的业务实现是通过平台层提供的技术服务和业务服务能力进行组合和组装实现的。这既可以通过传统的代码开发和服务调用来实现，也可以通过类似BPEL设计和建模工具等可视化的进行灵活配置和实现。

前端展现层

展现层主要是各种前端和界面实现技术，包括了JSP，HTML和现在主流的VUE, React框架等。展现层通过调用逻辑层的服务能力进行数据的存取和业务规则的实现，同时也包括了界面集成技术实现多个业务组件的界面集成。

技术架构设计

对于应用技术架构设计，主要还是参考传统的分层架构模式，结合SOA和组件化思想进行调整，其中重点是业务逻辑层和Web层两方面的内容的细化：

业务逻辑层

业务逻辑层本质是提供业务服务能力的服务组件层，其中包括了数据访问层，内部的技术组件，内部的服务接入软总线，外部的服务代理实现服务接入和服务发布。业务逻辑层最终的业务能力将以内部软总线的方式提供给Web层使用。

Web容器层和界面展现

该层的重点是实现标准的MVC模式。对于来自前端界面应用的请求信息先经过控制器处理后转给模型处理再进行视图层面输出，以实现界面显示和数据处理的分离。如通过Java的Struts框架来实现标准的MVC模式等。

集成架构设计

业务组件以 Web 服务的方式提供接口，通过企业服务总线连接。业务组件内部为了实现高可复用性和高效性，采用基于 OSGi 内部软总线标准进行构建模块，实现内部模块之间的松耦合。即在业务组件内部基于 OSGi 标准进行模块化设计，将业务组件进一步分解为松耦合的模块（Bundle），使得业务组件本身更加灵活。

基于 OSGi 标准，业务组件内部的模块通过一个具有动态加载类功能的微内核连接，统一管理各个模块。为了便于管理，将不同模块之间的类接口采用服务注册的方式进行管理，具有类动态加载功能的微内核和类接口管理组成类总线（JCB）的基本功能；为了更好的实现重用，有些模块是共用的，比如数据访问模块、日志管理模块等。

服务软总线

实现一个业务组件内部的服务注册、调用和服务管理，一般采用比较轻量的如OSGi标准来实现。软总线机制可以保证业务组件内部的进一步松耦合设计。

注：在当前微服务架构下，我们看到实际上组件之间的接口集成，已经不再需要类似OSGI这种内部软总线，而是直接采用去中心化的服务注册中心来完成集成工作。

服务组件和技术组件

服务组件是业务组件中唯一和外部进行交互的接口组件，包括了服务消费和服务调用均在服务组件完成。技术组件为服务组件的具体实现，内部功能的业务规则实现等。

服务代理

服务代理包括了服务消费代理和服务发布代理。业务组件本身要消费外部的服务，包括技术服务、流程服务和其它业务组件提供的业务服务，这些通过服务消费代理来完成。同时业务组件本身也需要向外部其它业务组件提供可复用的业务服务能力，因此需要将内部的服务接口进一步通过服务发布代理，发布为外部可访问的业务服务并注册到外部ESB服务总线上。

组件间整体框架集成

业务组件本身就是一个能够提供独立业务价值能力的小应用系统。组件的集成包括了组件的纵向集成和横向集成。组件的纵向集成即和PaaS平台技术服务能力的集成，通过集成后形成一个完整的应用。横向集成则是流程驱动的业务组件之间通过业务服务的横向协同和集成，通过横向集成加上和外层应用框架和门户的集成后，多个业务组件将构成传统的完整业务系统。

应用框架集成

在企业私有云PaaS平台的建设过程中，虽然基于平台+应用和SOA组件化架构思想真正实现了高复用和对业务的灵活应变能力，但是一个传统完整的业务系统已经被分解到了平台，服务和应用多个层面的技术组件，业务组件和服务中。因此这些分散的组件如何最终集成和还原为一个传统意义上完整的业务系统将成为应用集成必须考虑的重点内容。

结合实践经验，最好方式是通过门户+外层应用框架来实现总体的集成，具体参考：

以上图为例来看一个完整的业务系统。除了白色部分外，其余的组成部分都应该是有平台层统一规划建设和提供。应用外层框架和组件动态装载是重新还原一个传统意义上的业务系统的集成。应用外层框架首先是需要和门户进行集成，实现基本的统一认证和单点登录；其次是读取系统管理的基本参数和配置信息，实现外层界面和菜单资源等的装载和初始化；最后是根据应用配置文件灵活的对PaaS平台层的技术组件（系统管理，流程引擎），应用层的业务组件进行动态装载。

应用外层UI界面框架需要基于可重用，可配置的思想独立开发，该框架是一个包括了菜单描述文件，页面描述文件，工具栏描述文件，页面布局描述文件组成一个基本的页面框架，具体说明如下。

后台回复 学习资料 领取学习视频

如有收获，点个在看，诚挚感谢