1. 前言
什么是合适的，那么什么就是成功的。

这句话绝对适用于系统架构和设计。

最简单的例子，如果一个系统需要的实时反应，而不是复杂的业务。那么这个系统在设计的时候就应该更加关注与速度而不是业务的分层。

反过来说，如果一个系统能够容忍客户反应的迟钝，但是要求实现非常复杂，后期可扩展的业务逻辑。那么这个系统就应该有效的对业务进行抽象和分层。

在这里，我想分享几个我所知道的有趣的系统架构设计。



2. 一个反应超级快速的系统框架
2.1      该系统的要求
首先我们看一下，这个系统的需求概要

系统作用
一个保险系统

系统运行环境
全国各地的保险分销点，通过https协议访问

系统性能要求
要求响应速度高，但是并发量不是很大

系统未来扩展预期
系统未来的业务改动不会很大




2.2      该系统的框架设计



看到了没有，这个系统设计的多么有趣。没有臭屁的MVC，没有乱七八糟的XML配置文件，更没有数据库的ORM。

非常单纯的系统设计，非常简洁。

所有的业务处理都放在JSP中间，而所有的业务处理都是通过一个自定义的JSP Tag库。

接着通过这个JSP Tag库访问数据库中的PL/SQL，PL/SQL接着做数据库的增删改查。

整个系统中最重的地方就在自定义的JSP Tag库，数据库的连接，逻辑业务处理都在这里进行。

后期维护的时候，只要针对新业务扩展JSP Tag库就可以了，如果想变换数据库处理逻辑，就直接改写PL/SQL。

在整个系统的业务不是很庞大的时候，这样的系统设计是不是更好更实用呢？

另外，可以猜测，这个系统的设计者肯定是以前的银行系统的设计者，或者可能是以前COBOL时代的老程序员。因为这种短平快的设计思想绝对是那个时代的经典产物。

虽然已经很古老，但是依旧很实用。



3. 一个易于扩展的金融框架
3.1      该系统的要求
首先我们看一下，这个系统的需求概要

系统作用
一个行业内通用的证券系统，需要根据不同的证券公司的业务添加会修改具体的逻辑

系统运行环境
运营在小范围内，同时在线人数不大，但是要求系统的安全性和可重用性

系统性能要求
响应速度和并发量都不大，但是要求信息传输完全正确，不能失真

系统未来扩展预期
该系统其实是一个通用的证券系统平台，然后按照具体用户的要求定制系统模块


3.2      该系统的框架设计



我们可以看到，这个系统的框架明显的复杂了起来。

首先在客户端，它采用了MCO技术，让框架变成富B/S框架。

其次在，服务器层，他部分采用了Struts技术，但是有一点很特别的。

他在Action和Logic层次之间加上了一个Facade层次，这个最主要的原因就是减低控制层和逻辑层之间的耦合性，为了后期的扩展性做好准备。

简单的说起来，整个系统的客户端会有一个类似于ActiveX的控件在运行，专门用于解析服务器端发送来的NXML消息。而服务器端也不是单纯的发送HTTP请求来给客户端，而是通过框架发送有特定标识意义的NXML消息。

整个框架的技术层次如下：





最后提一下，这个框架是如何实现高可重用性的功能，如何满足不同客户快速定制化的要求。

那就是，对具体的业务抽象，抽象出高重用性的Logic，用来给予下方的具体业务类继承。具体的抽象Logic如下：

機能
Facade名
Logic名

登録
TemplateRegistFacade
TemplateRegistLogic

削除
TemplateDeleteFacade
TemplateDeleteLogic

订正数据
TemplateCorrectFacade
TemplateCorrectLogic

出报表
TemplateChohyoFacade
TemplateChohyoLogic

上传
TemplateUploadFacade
TemplateUploadLogic

下载
TemplateDownloadFacade
TemplateDownloadLogic

确认
TemplateApprovalFacade
TemplateApprovalLogic

确认解除
TemplateCancelFacade
TemplateCancelLogic

详细登録/更新/削除
TemplateCorrectallFacade
TemplateCorrectallLogic

Excel处理
TemplateExcelFacade
TemplateExcelLogic








--------------------------------------------------------------------------------

以上