在系统开发过程中，尤其是涉及到系统集成性软件开发过程中，我们经常会碰到类似这样的场景：团队中已经有一个产品化的软件系统，但该软件系统需要按照项目型进行实施，而每个项目由于面向不同客户在某一些产品组件上可能都会有其一定的独特性。这些特定的产品组件往往涉及到系统集成，由于集成技术和方案的不同而需要进行二次开发，如下图所示：
从上面的组件图中我们可以看到在产品系统中，部分产品组件（图中为产品组件A和B）的运行将依赖于系统集成组件，而系统集成组件的实现将视项目而定，图中的项目实现1、2和3分别对应了三个不同客户项目的要求，在实施过程中，通过组合产品组件和不同项目线的系统集成组件实现达到系统集成的需求，这也是这类场景的典型需求，本文中我们称之为产品-项目型系统。
针对产品-项目型系统开发，为每个项目都保存和维护一份完整的代码显然是低效和不符合产品化策略的。通常我们都会对涉及的不同项目系统集成部分进行抽象，如上图中的我们把系统集成组件梳理成一套集成接口，通过实现该套集成接口完成对不同项目可变部分的适配。产品-项目型系统设计的基本目标就是完成系统标准组件与可变组件之间的分离，但同时也要梳理一些其他因素，确保结构的完整性和高效性。
对产品-项目型系统而言，首先需要确保各种产品组件的标准化，即产品组件的业务逻辑和流程对所有项目而言都应该是统一的。要做到产品组件的标准化，需要对系统业务有较高的抽象，通常都会涉及到抽取标准的流程、接口和数据交互格式。标准化的产品组件是稳定、高效和没有bug的，如果一旦这些产品组件不能满足项目线的需求，则需要对其进行升级，但这种升级的频率应该远远低于系统集成组件的修改频率。
系统集成组件是可变部分，可变的是针对具体项目的系统集成方案和技术实现方法，但对产品组件而言，系统集成组件的接口和数据交互格式应该是标准的，以便和产品组件进行无缝整合。通常我们会提供一套默认的系统集成组件实现，如果项目上能直接使用默认实现就直接使用，如果不能就开发定制化的系统集成组件。
系统集成组件的设计过程中要基于模块化思想，因为产品组件流程会依赖不同的系统集成接口。由于业务流程的不同可能导致系统集成接口的服务提供方也是不同，而目前市面上存在多种系统集成技术，无论从服务调用方式，数据传输机制、结构封装等方面都有所不同。确保系统集成组件的独立性和模块化是实现集成服务有效管理的基础，对于多数情况下接口级别的系统集成而言，这点还是比较容易把握的。
数据推拉模式有两个维度：站在产品组件的角度和站在系统集成组件的角度。对系统集成组件而言，推模式是指具体项目中的服务提供者调用系统集成组件开放的标准服务来通知某些事件的发生，拉模式则是系统集成组件主动调用服务提供者的服务进行信息获取。对产品组件而言，推模式是指系统集成组件在特定事件发生时通过消息中间件来通知产品组件，而拉模式则是产品组件主动向系统集成组件发起请求并等待响应。
具体在两个维度上使用何种模式需要视情况而定，系统集成组件的推模式往往是一种优化的实现，但需要我们提供额外的服务供项目线调用，从而促使系统集成组件和项目线既是服务消费者又是服务提供者，双方都会有额外的接口及其维护成本，项目线并不一定能实现这种推模式，所以很多时候都只能使用拉模式；产品组件的推模式会对系统开发有一定要求和成本，但可以应对一些用户对实时性要求比较高的场景，由于产品组件和系统集成组件都是由我们开发，所以不存在技术实现方式上不可行的情况。
对系统集成而言，由于各个服务提供者的技术实现以及网络传输等环境上的差异化，可能会存在性能上的问题。面对性能问题，服务提供者的数据传输通常无法控制，但可以采用特定数据格式来减少产品组件和系统集成组件之间数据的传输量。另一方面，对于静态或者相对静态的数据而言，在系统集成组件中使用缓存进行数据保存也是常用的策略。
设计方案上我们从系统集成角度出发梳理关注点和细节。对于产品-项目型系统开发而言，我们希望达到的目标是保持产品组件稳定，通过适配来自项目线的不同服务实现达到系统动态组装的效果，从而为不同的项目构建出适合该项目的完整系统。对产品组件而言，关注的是系统业务逻辑，本文中不展开讨论，我们来看一下系统集成组件：
我们以系统集成组件为中心设计系统交互方案如下：
在实际开发过程中，本文提出的产品-项目型适配式系统开发模式具有一定的代表性。不管采用何种叫法，其本质是系统可变部分和不可变部分的抽象和解耦，不仅仅可以应用于系统集成领域，也可以扩展到系统设计和开发的方方面面。本文对这一思路的基本理念和设计进行了说明，后续会进一步阐述具体的实现方式和持续集成等主题。
原文地址：http://blog.csdn.net/lantian08251/article/details/41480983
