领域逻辑的组织可以分为三种主要的模式：

• 事务脚本
• 领域模型
• 表模块

    事务脚本

    保存领域逻辑最简单的方法是使用事务脚本，事务脚本的过程是：从表示层获得输入、进行校验和计算处理、将数据存储到数据库中、以及调用其他系统的操作等，然后该过程将更多的数据返回给表示层，中间可能要进行大量的计算来组织和整理返回值，基本的组织方式是让每个过程对应用户可能做的一个动作。

    事务脚本优点：

• 它是一个大多数开发者都能理解的简单过程（事务的四个特性：原子一致隔离永久）。
• 它能够与一个使用行数据入口或者表数据入口的简单数据源层很好的协作（数据库支持事务、框架支持事务）。
• 设定事务边界的方法显而易见：一个事务始于其脚本的打开，终于脚本关闭（代码实现）。

    领域模型

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

    表模块

    与领域模型的区别是领域模型中对数据库中每一个合同都有一个相应合同类的实例，每一行记录都能实例化，而表模块只有一个公共的合同类实例。

    选择

    架构师最大的工作就是根据以往的经验和现实的需求来进行方案选择。

    当领域逻辑简单时，不建议采用领域模型，复杂度增加时，其他方法就不再适用，后面的工作量是指数增长。这三种方法选择之后就不要轻易更改了，改变会引起大的工作量。这三种模式并不相互排斥，可以用事务脚本来处理一部分领域逻辑，也可以使用表模块和领域模型处理一部分。（如果这三种模式在很多模块中同时混杂使用，估计没有人会愿意看你代码了，就如同我们要维护项目时，看到别人的代码第一句话就是：这是哪个混蛋写的代码，当然也有时候是你自己，只是你忘记了）。

    服务层

    领域逻辑细分为两层：服务层、领域模型（表模块）。服务层应该包含哪些行为是个重要的决定，一是服务层只传值到下层，提供简单入口，二是将大部分业务逻辑都以事务脚本的形式置于服务层中，下层领域对象变为简单（这也是当前大多数的做法，大部分功能放置service层中，controller层只是简单的调用）。

    本节内容主要讲领域逻辑（业务逻辑）的设计层次划分，其实也就是我们开发中后端控制层的划分，目前很多项目都采用表模块或者事务脚本，一切围绕着数据库转，采用贫血模型，在service层做大量的处理，controller层看起来简单简洁，其service层看起来杂乱无章，基于项目任务完成驱动的方式，这样简单，每一块写完了就没有后续工作，无需重构，即使有需求变更，修改也方便，当然如果一直这样，那你就是重复劳动的机器，还不如写个程序自动实现。

    人总是要进步的，如果你在半年没有一小进步，两年一大进步的话，拿什么来致你已经在逝去的青春。