业务层组织模式
四种组织业务逻辑模式：事务脚本模式、活动记录模式、贫血型模式和领域模式
Transaction Script模式
- 事务脚本模式是组织业务逻辑的模式中最简单，也是最容易理解的。采用面向过程的方式来组织业务逻辑。
- 系统的一个流程又会被实现在为一个方法，一个方法会做完所有的事情。
优点：
- 它是大多数开发者都能够理解的一个简单的过程模型。
- 它能够与使用行数据入口或者表数据入口的简单数据源很好的协作。
缺点：当系统逐渐变大，业务逻辑也逐渐变复杂的时候，它的问题就会凸显出来，系统中存在大量的方法，而且方法中到处都是重复代码。
Active Record模式
- 活动记录模式：当系统中的业务类和数据库中表存在一一对应关系的时候，可以采用这个模式。
- 每个业务对象都代表了数据表中的一行数据，并且业务对象还包含了数据的增删改查方法
- 每个业务对象各自负责自己的数据持久化逻辑和相关的业务逻辑
Domain Model模式
- 在领域模型中，每个对象都承担了一部分的逻辑
- 领域模型中的没有业务类都是对现实世界中业务概念的抽象，它不仅仅包含业务活动中的数据，还包含了业务规则
- 把领域概念转换为业务类的过程叫“领域建模”，建模的结果就是得到业务模型。
- 与活动记录模式区别：领域模型的业务实体对如何持久化自己的数据一无所知，并且业务类也没有必要和数据模型一一对应。
Anemic Domain Model模式与实战
- 贫血型领域模型将与自身相关的业务处理逻辑全部转移到模型之外
- 缺点是领域服务类中的代码更加结构化了
业务层常用的设计模式
工厂方法模式
工厂方法（Factory Method）模式：定义一个创建对象的接口，但由子类来决定要实例化的类是哪个。主要目的就是隐藏对象的创建。
在工厂方法模式中体现了DIP依赖倒置原则。
装饰者模式
装饰者模式体现了一个很重要的设计思想：优先采用组合。而不是继承。
模板方法模式
- 模板方法模式定义了一个操作算法的骨架，而将一些步骤延迟到了子类。模板方法模式使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。
- 最直观的理解就是“模板”：包括变化和不变得两个部分，将变化的部分给子类实现。
- 模板方法中有定义“钩子”。钩子是一种被声明在抽象类中的方法。
状态模式
状态模式允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
策略模式
- 策略模式定义了一系列算法，并将它们分别封装了起来，让它们之间可以相互替换。
- 此模式让算法的变化独立于使用算法的客户
业务层常用的企业架构模式
层超类型模式
层超类型（layer Super），让某个类型充当一层所有类型的超类。
层超类型模式的思想极为简单：通过继承达到重用的目的。