Part 1 层
　　
　　层（layer）这个概念在计算机领域是非常了不得的一个概念。计算机本身就体现了一种层的概念：系统调用层、设备驱动层、操作系统层、CPU指令集。每个层都负责自己的职责。网络同样也是层的概念，最著名的OSI的七层协议。
　　
　　层到了软件领域也一样好用。为什么呢？我们看看使用层技术有什么好处：
　　
　　● 你使用层，但是不需要去了解层的实现细节。
　　● 可以使用另一种技术来改变基础的层，而不会影响上面的层的应用。
　　● 可以减少不同层之间的依赖。
　　● 容易制定出层标准。
　　● 底下的层可以用来建立顶上的层的多项服务。 当然，层也有弱点：
　　● 层不可能封装所有的功能，一旦有功能变动，势必要波及所有的层。
　　● 效率降低。
　　
　　当然，层最难的一个问题还是各个层都有些什么，以及要承担何种责任。
　　

Part 2 组织领域逻辑
　　
　　要组织基于层的系统，首要的是如何组织领域逻辑。领域逻辑的组织有好几种模式。但其中最重要的莫过于两种方法：Transation Script和Domain Model。选定了其中的一种，其它的都容易决定。不过，这两者之间并没有一条明显的分界线。所以如何选取也是门大学问。一般来说，我们认为领域逻辑比较复杂的系统可以采用Domain Model。
　　
　　Transation Script就是对表示层用户输入的处理程序。包括验证和计算，存储，调用其它系统的操作，把数据回传给表示层。用户的一个动作表示一个程序，这个程序可 以是script，也可以是transation，也可以是几个子程序。在例子1中，检验，在购物车中增加一本书，显示递送状态，都可以是一个 Transation Script。
　　
　　Domain Model是要建立对应领域名词的模型，例如例1中的书、购物车等。检验、计算等处理都放到领域模型中。
　　
　　Transation Script属于结构性思维，Domain Model属于OO思维。Domain Model比较难使用，一旦习惯，你能够组织更复杂的逻辑，你的思想会更OO。到时候，即使是小的系统，你也会自然的使用Domain Model了。
　　
　　但如何抉择呢？如果逻辑复杂，那肯定用Domain Model：如果只需要存取数据库，那Transation Script会好一些。但是需求是在不断进化的，你很难保证以后的需求还会如此简单。如果你的团队不善于使用Domain Model，那你需要权衡一下投入产出比。另外，即使是Transation Script，也可以做到把逻辑和基础架构分开，你可以使用Gateway。
　　
　　对例2，毫无疑问要使用Domain Model。对例1就需要权衡了。而对于例3，你很难说它将来会不会像例2那样，你现在可以使用Transation Script，但未来你可能要使用Domain Model。所以说，架构的决策是至关紧要的。
　　
　　除了这两种模式，还有其它中庸的模式。Use Case Controller就是处于两者之间。只有和单个的用例相关的业务逻辑才放到对象中。所以大致上他们还是在使用Transation Script，而Domain Model只是Database Gateway的一组集合而已。我不太用这种模式。
　　
　　Table Module是另一个中庸模式。很多的GUI环境依托于SQL查询的返回结果。你可以建立内存中的对象，来把GUI和数据库分开来。为每个表写一个模块，因此每一行都需要关键字变量来识别每一个实例。
　　
　　Table Module适用于很多的组件构建于一个通用关系型数据库之上，而且领域逻辑不太复杂的情况。Microsoft COM 环境，以及它的带ADO.NET的.NET环境都适合使用这种模式。而对于Java，就不太适用了。
　　
　　领域逻辑的一个问题是领域对象非常的臃肿。因为对象的行为太多了，类也就太大了。它必须是一个超集。这就要考虑哪些行为是通用的，哪些不是，可以由其它的类来处理，可能是Use Case Controller，也可能是表示层。
　　
　　还有一个问题，复制。他会导致复杂和不一致。这比臃肿的危害更大。所以，宁可臃肿，也不要复制。等到臃肿为害时再处理它吧。