结构分层的经验谈

结构分层的经验谈-转贴自卢彦Blog

为了将业务规则从界面和数据库中剥离出来，通常的做法是抽象出一个业务逻辑层出来，专门负责对业务逻辑进行处理。一般多采用三层结构，既表现层，业务层和数据层。

当开发人员在以前的两层结构中痛苦煎熬了很长一段时间，突然看到了三层结构的解决方案的时候，一般会有终于找到了救世主的感觉。但是这种感觉往往会导致掉到另外一个同样恐怖的陷阱“过度设计”中。在我以前曾经供职的一家公司，以前都是把SQL语句直接写在ASPX页面的，后来在读到了一些关于多层结构方面的资料之后，一下子又把整个系统分成了：表现层（ASPX）、接口外观层（IF），业务外观层（BF），数据访问外观层（DAF），数据访问层（DA）和数据访问组件（SQLHelper）。但是我并没有吸取教训，导致后来也犯了同样的错误。

犯错误的原因有很多，不过主要是因为没有一个比较明确的如何分层的指导性原则。假如说我们分层的原则是为了抽象逻辑，分三层的原因是要让业务逻辑和界面及数据库解除耦合，那么如果按照这个分层原则，我把逻辑重新归类更加细的分为四层、五层、六层行不行呢？如果不行，那是什么原因不行呢？在没有正确的原则指导下，分层技巧很容易被滥用，导致分出许多没有必要的层出来。无端的增加了开发和维护成本，以及更重要的是增加了重构的代价，降低了团队的敏捷能力。

面向对象架构设计大师Martin Fowler在介绍如何设计分布式系统的时候曾说过：分布式系统的设计原则的第一条是，不要使用分布式。他的意思当然不是说要绝对禁止使用分布式设计，而是劝导人们尽量把问题简单化。能不分布式设计的，就不要分布式设计。

我套用他的这句话提出我对分层的感受就是：多层结构系统的设计原则第一条是，不要使用多层结构。

当然我的意思也并不是说层数越少就越好，而是希望你能清醒的认识到增加层数会增加结构的复杂性，不要轻易的作出分层的决定，一定要到感觉必须要增加一层才能解决问题的时候，再来决定增加一层。

过多的层次除了会给系统带来不必要的复杂性外，还会影响你的系统结构设计。如果你打算采用面向对象的领域模型来设计系统的话，在业务系统内的分层会给面向对象系统的设计带来很多麻烦，会很容易走回到事务脚本的老路上去。关于这一点，我在面向对象系统设计经验谈这篇BLOG里详细的谈到过，这里就不再赘述。

下图是我们最终定型的应用系统结构层次：

总结一下：

1. 建立一个完全面向对象建模的领域模型层，让这个层尽量处理多的业务逻辑。其它层尽可能的薄一点，把业务逻辑都转移到领域模型层中。
2. UI尽可能和领域模型贴近一点，中间不要经过太多中转，物理边界也尽可能的少。
3. 业务对象只能有一套，也就是领域模型。只要出了领域模型层，外面全部是零散数据，没有对象的概念。
4. 只有在领域模型层才可以处理对象。
5. 如果一定要分布式。全部用简单数据类型通过接口访问领域模型。

 

这个分层结构其实是经历了多次精简完成的，所有的感触都归结为一句话：不要过度设计，简单就是美。