架构应用差别

项目实施概念：

1）  业务处理流：业务处理流指完成一个业务处理逻辑的完整步骤。

2）  处理节点（行为）：在一个完整的处理流中的每一个可划分的、可重复调用的处理单元。

3）  处理流：处理流是与业务处理流一一对应的、业务处理步骤与处理节点一一对应的。

4）  项目可变性：项目可变性指项目实施在项目每一个阶段因业务需求发生变更或补充，而做的项目架构或细节的调整；

5）  项目不可变性：项目不可变性指项目实施到项目进程过半，因为业务调整而对项目总体架构的相应调整，造成项目严重延期，甚至项目推倒（失败）重新开发。

6）  业务需求截止日：业务需求截止日指客户与开发商之间根据协议制定在项目实施中的业务需求最终变更日期。在业务需求截止日之前业务需求发生变更，开发商的应用总体架构基本不会受到影响，即使有影响，开发商也无条件进行相应的总体架构变更。在业务需求截止日之后，如果影响项目总体架构实施，甚至影响项目实施进度，客户应对需求变更造成的影响，承担额外的项目实施费用。

7）  Module项目：Module项目指AS400平台下，应用项目采用的实施处理单元95%以上都是module。

8）  固定业务处理流：固定业务处理流指同类业务处理流中，完全相同的、连续的处理节点的集合。

 

项目实施好处：

1）  处理流实施单纯，项目容易实施；

2）  功能点唯一化；业务划分清楚；功能点开发独立。

3）  项目实施，或者运维单一、简单。

4）  业务与开发分离；

5）  开发者无需知道具体业务处理；

6）  动态测试/静态项目实施；

7）  大大节省项目开发和运维成本；

8）  项目整体代码运行速度快；因为都是静态调用；

9）  容易转化为流多线程处理并发处理模式；

10）  灵活性较强，容易组成新的业务处理流；

11）  灵活性较强，容易组成同类新的业务处理流；

 

项目实施敝处：

1）    灵活性较差；

2）    如果业务处理逻辑发生变化，增减或减少一个或多个处理节点，就必须修改代码；

3）    运维人员在修改代码时，必须首先了解业务处理逻辑，才能修改程序处理逻辑；、

4）    对项目而言，存在大量重复代码，比如公共处理节点；

5）    每一个公共处理节点的变化，涉及多个程序代码的修改；

6）    业务变更会增加项目实施成本，甚至无法更改；

7）    运维人员要求相对对应用系统分析能力和程序代码处理能要求较高，增加运维费用；

8）    程序规范较难控制。

9）    调用参数复杂，处理代码增加；

10）一旦业务发生变化，程序主处理流与调用部分都要做增减，或调整；

11）涉及项目总体，添加应用系统的风险；

12）运维成本增加；

13）项目概要设计没有对详细设计有制约作用；

 

 

业务处理流在项目实施中的表现形式：

一个业务处理流程有多种同类业务处理流程，在同类处理流程中有多个共公的处理节点。比如定期存款业务，存在多个储种。每一个储种都有固定的定期存款公共处理节点，比如，储蓄账户验证或卡号验证、现金操作、记会计账、记流水账等操作步骤。而每一个储种有自身特殊的处理节点。

假设这个处理流A有如下处理节点：

StepOne

StepTwo

StepSpc1

StepThree

StepFour

假设这个处理流B有如下处理节点：

StepOne

StepTwo

StepSpc2

StepThree

StepFour

假设这个处理流C有如下处理节点：

StepOne

StepTwo

StepSpc3

StepThree

StepFour

……

常见的项目实施方案中，对上述处理逻辑的编写代码处理模式有以下几种：

1）  如果把每一个处理流流编写为一个完整的代码，比如一个PGM。

项目实施好处：1）

存在弊处：1）-12）

2）  一个PGM实现一个业务处理逻辑；除公共节点外，根据参数，用IF或select进行选择判断，处理相应的特殊节点。

项目实施好处：11）

存在敝处：1）-12）

3）  如果一个程序对处理节点都是调用关系。

项目实施好处：

存在敝处：。

4）  调用采用表驱动；即每一个处理步骤都写成*pgm。*pgm的名称放在一个驱动表中，在主处理逻辑*pgm中，在一个执行点，到驱动表中检索到相关的程序名，然后把这个步骤的程序名作为变量，再调用这个*pgm。

项目实施好处：10）11）

存在敝处：1）-12）+

    另外，当功能点处在一个大数量时，无法确定新增加的功能点*pgm是否在项目中是唯一的。因为不能保证应用系统功能点唯一性，在项目功能点巨大时，对更新或者增加的功能点，无法保证功能点组合的业务处理逻辑在应用系统业务处理流的全局唯一性。从而，造成项目处在运维期间，随着驱动表的功能点的增加，应用系统的雪球越滚越大，一方面，应用系统更改业务处理逻辑无从下手；另一方面，无法根据业务发展，及时增加新的应用子系统。另外，采用表驱动，程序调用是动态调用，会影响应用系统的运行速度。

5）  原子处理交易模式：即把交易处理流中的每一个步骤，或每一个处理节点都化为一个原子交易。交易是相关的原子交易组合的。如果业务处理流中增加一个处理节点，就增加一个新的原子交易。组合业务交易处理流程，或用人为进行组合；或用一个专用的开发平台进行组合，这个平台存在的形式是多样的。原子处理交易模式目前广泛用于银行核心系统。

 

主要好处：灵活性较强。

主要弊端：几乎所有采用原子交易模式的项目，都没有制约每一个原子交易的处理范围，开发者可以根据自己了解的业务处理逻辑，把多个处理节点都集中到一个原子交易中进行处理。因为没有原子交易规范，所以项目范围内存在大量重复处理功能点。另外，采用原子交易模式的项目，几乎各应用子系统之间都采用各自应用子系统对外提供的接口API。如果一个业务流程在多个子系统间有交叉处理，如果这个业务处理流的发起在某个子系统，且有多个连续的处理节点只能在外部子系统进行处理，如果项目对原子交易有规范制约，这个子系统对外子系统的API调用势必进行多次，会增加项目整体的复杂度，对频繁API调用增加系统资源额外开销和代码的复杂度。如果项目对原子交易没有规范制约，即回到上面刚刚提到过问题，项目会存在大量重复处理节点。重复处理节点对业务扩充和添加新的业务处理流都是一个无法克服的障碍。

 

补充一：

 

结论与新的挑战：

以上五种项目实施架构都有无法克服的缺点，造成这些问题的归纳成为下列项目实施因素，这些因素成为已经成为项目实施最关键的因素：

1）              代码子交易的最小处理规范，即项目最小处理单元的规范。最小处理单元规范的尺度是处理单元与处理单元调度量的一个平衡点。

2）              合理的规范最小处理单元，同时也会衍射出最小处理单元的频繁调度而对应用系统运行性能的影响。在AS400平台下，势必把最小处理单元规范到能够采用静态调用，甚至规范到采用多线程处理模式，即最大化地充分使用AS400的处理机制。

3）              在实施最小处理单元规范后，业务处理逻辑也必须做相应的最小处理逻辑规范，把这些处理规范实施在项目概要设计中，与项目实施的最小处理单元有机的联系起来，做到业务分割层次清晰，相应的处理单元实施简单易行。

4）              把项目概要设计阶段实施的工作做到业务的细化与分割与项目最小处理单元的规范描述、与之上的最小处理单元的归类控制处理单元、与之上的最小处理单元归类的子系统处理单元、与之上的子系统处理单元的延伸扩展处理单元等有机的、无缝的、无重复关系的、高效率处理结合起来，完成项目的实施。

（未完，待续）