今天看到一篇感受很深，特转载。

1. 前言

什么是合适的，那么什么就是成功的。

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

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

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

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

2. 一个反应超级快速的系统框架

首先我们看一下，这个系统的需求概要

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

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

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

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

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

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

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

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

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

首先我们看一下，这个系统的需求概要

系统作用	一个行业内通用的证券系统，需要根据不同的证券公司的业务添加会修改具体的逻辑
系统运行环境	运营在小范围内，同时在线人数不大，但是要求系统的安全性和可重用性
系统性能要求	响应速度和并发量都不大，但是要求信息传输完全正确，不能失真
系统未来扩展预期	该系统其实是一个通用的证券系统平台，然后按照具体用户的要求定制系统模块

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

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

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

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

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

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

几个有趣的系统架构[转]

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

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

原文来源：http://blog.****.net/nanjingjiangbiao/archive/2010/08/17/5819364.aspx