企业应用的分层设计理念

无论是在J2EE平台还是在.Net平台下，对于企业级应用来说，一个基本的设计思想就是分层。一提到分层，很多人都知道三层结构，连刚刚入门的程序员都能说出一些道道来。但是，真正能为企业级应用划分出好的层级结构来，还的的确确不是每个架构师都可以搞定的事情。尤其是具有一定规模的企业应用，其中有很多原则性的东西和一些技巧性的东西，还有一些经验性的东西。如果不加以注意或考虑不周的话，很可能你的设计就会致项目于死地。我最近就亲身经历这样一套销售相关系统，缺乏对整个项目的整体设计，在UI中直接写SQL访问数据库，系统也不大，三四十张表，但是性能相当低下，经常down机。最终发现，失败不是开源框架和数据库的问题，更不是应用服务器和硬件配置的问题，根源在于拙劣的设计导致。希望以后大家在做项目的时候能注意点。

常见的层次结构
从最常规的分层结构来说，系统层次从上到下依次为：
表现层（UI Layer）：主要是客户端的展示。
服务层（Business Service Layer）：直接为客户端提供的服务。
领域层（Domain Layer）：系统内的领域活动。
数据访问层（DAO Layer）：数据访问对象，操作数据库。

分层结构设计的原则
其中关于分层，还是有些指导原则的：
1）上层总是依赖其下层，依赖关系不跨层。
2）在设计的时候，应该从服务层为出发点，把系统需要提供的功能抽象为服务，然后进行分析，确定Service接口中的方法。是要控制Service的数量，通常将一个模块的服务都集中到一个Service中来处理。
3）设计不能从数据库的表出发，创建DAO，再创Domain，然后Service，这实际上是对系统分层的误解。
4）服务层的实现依赖于领域活动。系统最核心的设计就是将系统中的实体划分为领域模型。
5）每个接口的职责范围明确有界。每个接口都应该关注的是自己的那一块，而不要牛槽伸出个狗舌头。最典型的例子就是一个DAO中胡乱操作别的表。

切不能为了分层而分层
在我所做的系统中，常常看到一些糟糕的编码：系统设计从数据库的表开始，一个表对应一个DAO，一个DAO对应一个domain，一个Domain对应一个Service，实际上Service的接口和DAO的接口基本上一样！导致Service的接口方法超多！到了表现层，前台程序员在写Action的时候，反复的调用各种Service方法，代码凌乱而且繁琐。说实话，这就是典型的为了分层而分层。这种分层就相当于重复调用，没有任何意义。
正确的设计应该是，一个领域活动会聚合对应一个或一组DAO，来完成一个领域活动。而一个服务可能包含多个领域活动。比如一个转账的业务，对应两个领域活动。两个帐户的金额分别发生变化，需要操作一组领域活动，而每个活动需要操作很多表（调用多个DAO）。事务的控制我们可以放到Service层。

时下的领域模型驱动设计
目前，越来越多的架构师喜欢领域模型驱动设计，针对系统的领域模型建模，然后上层直接是Service，Service下面就是领域活动层，从而去掉了DAO层，这样做的优点是系统设计思路更清晰，目标更明确。但缺点是当领域活动发生变化的时候，会引起领域活动层代码的变化。并且，当要更换持久化框架或者技术时候，领域活动要重新实现。但综合考虑起来，这样带来的优点也很多，而实际上更换数据库和持久化框架的情况很少，因此这样的设计也是有其合理性一面的。这样做实际上是将原来的DAO和Domain层合二为一，但上层的设计思路还是一致的。