何时分层
这样的三个例子，就要求我们不能够一概而论的解决问题，而是应该针对问题的具体情况制定具体的解决方法。这三个例子比较典型。
第二个例子中，可能需要严格的分成三个层次，而且可能还要加上另外的中介(mediating)层。例3则不需要，如果你要做的仅是查看数据，那仅需要几个server页面来放置所有的逻辑就可以了。
我一般会把表示层和领域层/基础架构层分开。除非领域层/基础架构层非常的简单，而我又可以使用工具来轻易的绑定这些层。这种两层架构的最好的例子就是在VB、PB的环境中，很容易就可以构建出一个基于SQL数据库的windows界面的系统。
这样的表示层和基础架构层非常的一致，但是一旦验证和计算变得复杂起来，这种方式就存在先天缺陷了。
很多时候，领域层和基础架构层看起来非常类似，这时候，其实是可以把它们放在一起的。可是，当领域层的业务逻辑和基础架构层的组织方式开始不同的时候，你就需要分开二者。
更多的层模式
三层的架构是最为通用的，尤其是对IS系统。其它的架构也有，但是并不适用于任何情况。
第一种是Brown model [Brown et al]。它有五个层:表示层(Presentation)，控制/中介层(Controller/Mediator)，领域层(Domain), 数据映射层(Data Mapping), 和数据源层(Data Source)。它其实就是在三层架构种增加了两个中间层。控制/中介层位于表示层和领域层之间，数据映射层位于领域层和基础架构层之间。
表示层和领域层的中介层，我们通常称之为表示-领域中介层，是一个常用的分层方法，通常针对一些非可视的控件。例如为特定的表示层组织信息格式，在不同的窗口间导航，处理交易边界，提供Server的facade接口(具体实现原理见设计模式)。最大的危险就是，一些领域逻辑被放到这个层里，影响到其它的表示层。
我常常发现把行为分配给表示层是有好处的。这可以简化问题。但表示层模型会比较复杂，所以，把这些行为放到非可视化的对象中，并提取出一个表示-领域中介层还是值得的。
领域层和基础架构层之间的中介层属于本书中提到的Database Mapper模式，是三种领域层到数据连接的办法之一。和表示-领域中介层一眼，有时候有用，但不是所有时候都有用。
还有一个好的分层架构是J2EE的架构，这方面的讨论可以见『J2EE核心模式』一书。他的分层是客户层 (Client)，表示层(Presentation)，业务层(Business )，整合层(Integration)，资源层(Resource)。差别如下图:
J2EE核心 ISA
客户层 运行在客户机上的表示层
表示层 运行在服务器上的表示层
业务层 领域层
整合层 基础架构层
资源层 基础架构层通信的外部数据
微软的DNA架构定义了三个层:表示层(presentation)，业务层(business)，和数据存储层(data access)，这和我的架构相似，但是在数据的传递方式上还有很大的不同。
在微软的DNA中，各层的操作都基于数据存储层传出的SQL查询结果集。这样的话，实际上是增加了表示层和业务层同数据存储层之间的耦合度。DNA的记录集在层之间的动作类似于Data Transfer Object。
