分层

表现层|领域层|数据层

系统分层的好处

• 在无需过多了解其他层次的基础上，可以将某一层作为一个有机整体来理解。例如，无需了解以太网的工作细节，就可以在tcp上构建ftp服务
• 可以替换某层的具体实现（针对接口编程）
• 可以将层次间的依赖减到最低
• 分层有利于变准化的工作。tcp和ip就是关于他们各自层次如何工作的标准
• 一旦构建好某一个层次，就可以用它为很多上层服务提供支持。因此tcp/ip同时被ftp/telnet/ssh/http使用。

分层的缺陷

• 级联修改，分层之后如果有功能修改可能会需要每层都进行修改。
• 影响性能，层次太多调用次数过多会影响性能。

note

• 分层的粒度不一定的package级别的，也可以是class或者method. 需要根据实际情况进行选择。
• 领域层和数据层不要依赖表现层。
• 区分领域逻辑和其他逻辑（request/response 的相关逻辑数据其他逻辑）
• 事务脚本（贫血型）和领域模型（充血型）
• 尽可能保证代码在单一进程内完成。

事务脚本

从表示层获得输入，进行校验和计算处理、将数据存储到数据库中、以及调用其他系统的操作等。然后，该过程将更多的数据返回给展示层， 中间可能要进行大量的计算来组织和整理返回值。基本的组织方式是让每一个过程对应的用户可能做的一个动作。所以，我们可以将这一模式想象成一个动作或者业务事务的脚本。

优点

• 大多数人能够理解的简单过程模型
• 能够与一个使用行数据入口或者表数据入口的简单数据源层进行很好的协作
• 设定事务边界的方法显而易见：一个事务始于其脚本的打开，终止于脚本的关闭。很容易用工具在幕后设定事务边界。

缺点

领域逻辑复杂的时候事务脚本的方式就会出现很多问题。

• 多个事务存在相同的操作的时候，事务脚本中就会出现很多重复的冗余代码。
• 领域结构混乱

解决方案

引入对象，使用领域模型，在开始的时候主要围绕领域中名词来进行组织，例如：租赁系统中的租约、资产等。进行校验和计算的逻辑会至于领域模型中。用领域模型而不是事务脚本正是面相对象程序员推崇的“理论体系转换”的精髓。

在领域模型中，不再是一个过程来控制用户某一动作的逻辑，而是由每一个对象都承担一部分相关逻辑。

映射到关系数据库

简单的事务脚本模型中我们可以讲领域对象直接与数据库表字段进行对应，而在复杂的领域模型中我们通常需要构建一个数据映射器来与数据库表的字段进行一一映射，这样我们的领域对象可以使用映射对象来进行数据库操作。