【平台+原创】SOA组件化思想在项目中的落地(Primeton EOS)

http://p.primeton.com/articles/53b52496e138234886000003

摘要：分层架构是降低软件复杂度的最常用手段之一，从软件的可变性管理和降低应用复杂度来讲，软件平台必须要层次化，基于技术平台搭建业务平台，进行业务组件积累，再基于业务平台进行业务应用开发。普元平台提供了强大的技术平台支撑，提供了统一的应用软件架构和流程引擎，从而收敛了技术路线；同时为应用系统开发提供一致的开发、运行、管理一体化框架。合作伙伴进行业务平台搭建和业务组件积累，并结合项目需求开发最终的业务系统。

1 普元平台的内涵

1.1 层次化

分层架构是降低软件复杂度的最常用手段之一，从软件的可变性管理和降低应用复杂度来讲，软件平台必须要层次化，基于技术平台搭建业务平台，进行业务组件积累，再基于业务平台进行业务应用开发。普元平台提供了强大的技术平台支撑，提供了统一的应用软件架构和流程引擎，从而收敛了技术路线；同时为应用系统开发提供一致的开发、运行、管理一体化框架。合作伙伴进行业务平台搭建和业务组件积累，并结合项目需求开发最终的业务系统。

1.2 组件化

在多应用多产品情况下，软件平台需要基于SOA思想和标准规范进行组件化，所支撑的上层应用则能根据需求的不同集成所需要的组件。

1.3 体系化

在多应用多产品情况下，软件平台需要基于SOA思想和标准规范进行组件化，所支撑的上层应用则能根据需求的不同集成所需要的组件。

2 构件化设计原则

2.1 从业务开发看构件化

2.1.1 SOA的构件化业务模型

SOA的企业应用架构体现在以下3个维度：1）业务维度：关注的是构件化/流程化的业务模型和服务构造；2）技术维度：关注的是服务化和交互协同的技术架构；3）管理维度：关注的是IT和业务的可管控和可治理框架。普元平台从平台的技术分层架构、管控和治理架构上对技术维度和管理维度都提供了有力的支撑。从业务维度来看，普元建议采用构件化的业务模型来支撑业务的构件化和流程化，主要分为以下几个层面：

 业务流程：

业务构件对外提供的服务，通过业务流程组织和使用

 业务构件：

业务层面复用，解决某一业务领域的问题

 平台构件：

平台类的复用，例如工作流、内容管理、规则、报表等

 技术构件：

技术层面复用，例如字符处理、菜单、日志

2.1.2 构件化的业务开发与项目导向的区别

构件化的业务模型与传统项目导向的应用模式的区别，主要是项目导向的应用模式，只从项目应用的需求出发，业务设计和资源配置只在项目组内部考虑，而没有从业务服务复用和价值最大化的角度考虑，典型的结果就是各个项目成为“竖井式”的应用，项目资产耦合度很高、很难拆分，IT资产得不到有效的利用。当然，即便是项目导向的开发，也与整个项目的总体规划和架构设计质量相关。

构件化的业务模型，是把日渐复杂和不断变化的业务系统通过分层、分模块地设计分解为若干相对独立又不相交的业务构件，并进一步分析这些业务构件对于企业总体业务的基础性、差异化和核心度，然后再针对性地实现、改良和革新。通过统一的业务蓝图规划和业务模块分析来实现统筹分治，是把复杂问题进行统筹和分而治之的一种业务设计模式，并根据企业的业务目标和关键业务指标（KPI）来分清各个业务模块的轻重缓急策略。这种模式在业务服务的物理部署上也更为的灵活，业务构件的模块独立性和规范性带来了更好地计算资源配置和虚拟化部署，进一步提升了IT的资产效率。

2.2 构件包设计原则

构件化的设计思想在普元平台上的落地，最典型的就是构件包的设计。构件包是普元平台系统发布和复用的基本单位，它由逻辑流、页面流、服务构件、Java代码、页面资源等组成。既然构件包作为普元平台资产管理和复用的基本单位，那么构件包的划分的合理性也就直接影响了业务系统最终的可管理性和可复用性。一个构件包通常能够完成一个相对独立、完整的业务功能。

一个构件包相当于一个业务模块，对应于应用系统中一个相对独立的业务域。一般原则：在总体设计时进行构件包规划和设计，模块进行切分时大小适中（功能相对独立和完整，适合1-2人独立完成）, 粒度太大会影响业务的复用；粒度太小会增加管理复杂度。每个构件包对应一个与其名称一致的web路径。一般可复用的通用功能或页面可单独抽取到一个公共构件包中。被多个模块调用的基础业务数据和功能最好作为独立的构件包存在。划分构件包时应避免构件包之间的相互依赖，如构件包A依赖构件包B的资源，而构件包B又要使用构件包A的资源，这时应该将构件包A，B相应的资源抽取到公用构件包C。

合理划分构件包的另一个好处是构件间的依赖和引用关系非常明确，如果出现循环引用，系统会自动进行检查和提醒，对于代码的重构和修改系统也可以直接反应影响范围，便于进行管理和维护。每一个构件包都可以有独立的版本管理，可以独立发展和变更，便于进行后期的运维。

3 流程设计改进建议

3.1 流程设计原则

流程设计需要遵循KISS原则(keep it simple and stupid)，尽量保证流程的简单和清晰。这样便于流程的监控和改进。在流程分析设计过程中尽量保证流程的清晰完整，尽量做到一个流程只做一件事情。

3.2 现状描述

目前项目只设计了一个大的业务流程，把业务管理的各个环节全部在该流程中囊括了。

3.3 改进建议

建议按照业务管理的各个阶段对流程进行拆分，定义一些相对独立的子流程，再通过子流程串联形成完整的业务管理大流程。这样，每个小流程发生改变时只需要对一个子流程进行调整，而不是针对一个复杂的大流程的具体细节进行调整。同时，抽取一些可能复用的子流程，有些流程如：签收流程可能会被多个不同的子流程复用。