解决方案:业务系统组件化开发概述和技术架构设计

  现在介绍下模块化研发方面的内容，在上面我讲解微服务的之后就早已提及，实际上微服务原本就是特色的业务平台模块化研发的一个更新。懂得基础的模块化研发和科技架构设计是只是过渡到当前主流的微服务架构思想的基础。

  组件化开发概述

  在此处先介绍和表明下基于模块化研发带来的优势。

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

  其次，产品组件化后可以真正推动完整意义上的按部件进行产品配置和销售，用户可以选用购买这些部件，组件之间可以灵活的进行装配。另外，包括例如配置管理、开发、测试、打包、发布完全控制到模块层面，会带给其他众多弊端，如果一个模块进行小版本更新，提供给内部的接口没有任何变动，其它模块完全可以不用做任何测试。

  组件化研发策略在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的框架来推动标准的MVC范式等。

  集成架构设计

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

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

  服务软总线

  实现一个业务组件内部的服务登录、调用和服务管理，一般采取非常轻量的如OSGi标准来推动。软总线体系可以确保业务组件内部的进一步松耦合设计。

  注：在当前微服务架构下，我们发现实际上部件之间的接口集成，已经不再必须类似OSGI这种外部软总线，而是直接引入去中心化的服务注册中心来完成集成工作。

  服务组件和技术组件

  服务模块是业务组件中唯一和内部进行交互的接口模块，包括了服务消费和服务调用均在服务模块完成。技术部件为服务模块的详细实现博客管理系统业务流程，内部用途的业务规则实现等。

  服务代理

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

  组件间整体框架集成

  业务组件本来就是一个无法提供独立业务价值能力的小应用平台。组件的集成包括了模块的竖向集成和横向集成。组件的竖向集成即和PaaS平台技术服务素质的集成，通过集成后产生一个完整的应用。横向集成则是步骤驱动的业务组件之间借助业务服务的纵向协同和集成，通过纵向集成加上和外层应用框架和门户的集成后，多个业务组件将组成特色的完整业务平台。

  应用框架集成

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

  结合实践心得，最好方法是借助门户+外层应用框架来推动总体的集成，具体参考：

  以上图为例来看一个完整的业务平台。除了白色部份外，其余的构成个别都必须是有系统层统一规划建设和提供。应用外层框架和模块动态装载是再次还原一个特色意义上的业务平台的集成。应用外层框架首先是必须和门户进行集成，实现基本的统一认证和单点登录；再者是调用系统管控的基本参数和配置信息，实现外层界面和菜单资源等的装载和初始化；最终是按照应用配置文件灵活的对PaaS平台层的科技部件（平台管理，流程引擎），应用层的业务组件进行动态装载。

  应用外层UI界面框架必须基于可重用，可配置的观念独立研发，该框架是一个包含了菜单描述文件，页面描述文件，工具栏描述文件，页面布局描述文件构成一个基本的页面框架，具体表明如下。