4.业务层设计
业务层设计
业务层组织模式剖析
1.1事物脚本模式-Transaction Script模式
1.1.1概念
采用面向过程的方式来组织业务逻辑。通常情况下，系统的一个流程又会被实现为一个方法，然后所有的这些方法又会被组织在一起，放在一个静态的类中。
实现流程的方法包含业务逻辑的校验域验证，数据的持久化，以及其它的一些相关操作，也就是说，一个方法会做完所有的事情。
1.1.2优缺点
优点：
简单好理解。
能够与使用行数据入口或表数据入口的简单数据源很好的协作。
缺点：
业务逻辑复杂的时候，维护困难。
1.2active record模式
1.2.1概念
每个业务对象都代表了数据表中的一行数据，并且业务对象还包含了数据的增删查改方法。
每个业务对象各自负责自己的数据持久化逻辑和相关的业务逻辑。
1.2.2特点
这种模式很适合"业务对象和数据表一一对应"的应用程序。
同时也比较适合"数据为先"的应用程序：根据现有的数据库来组织和建立业务模型。
1.3领域模型
1.3.1概念
在领域模型中，每个对象都承担了一部分的逻辑。领域模型中的每个业务类都是对现实世界中业务概念的抽象，因此它不仅仅包含了业务活动中的数据，还包含了业务规则。把领域概念转换为业务类的过程叫"领域建模"，建模的结果就是得到业务模型。
领域模型和活动记录模型最大的区别就在于：领域模型的业务实体对如何持久化自己的数据一无所知，并且业务类也没有必要和数据模型一一对应。
1.3.2领域建模应用的过程
1.建模
得出业务模型和他们之间的关系。
- 建立对应的领域业务类
- 构建领域模型服务层
处理领域逻辑常见的方法就是将领域层细分为两层，即在领域层中把服务类独立出来，作为服务层，如下图所示：
1.4anemic domain model模式
贫血型领域模型模式和领域模式很想，但他们确实不同，domain model的领域类中包含了自身的业务逻辑和数据，以及对象之间的关系。贫血型领域模型的领域类与自身相关的业务狐狸逻辑全部转移到了模型之外，有专门的业务规则类，这使领域类成为了一个简单的数据对象。
缺点：领域服务类的代码更加结构化了，这和transction script模式很想，同样也就会带来和transaction script模式一样的问题。
1.5业务层组织模式比较
下图所示为各种组织模式的关系：
很多时候，选择那种模式很大程度上取决于经验，一旦做出选择，如果中途再改变的话代价会比较大。
其实这几种模式不是相互排斥的关系，很多时候即使采用的是领域模型来组织业务逻辑的，但是服务层还是采用事物脚本的模式来实现的。
2.业务层常用的设计模式解析
2.1工厂方法模式
如上图所示:工厂方法模式解决的是对象实例化的问题，将客户端类与依赖类解耦，通过都依赖于高层抽象，利用工厂来实现具体的实现类的实例化。
2.2装饰者模式
通过组合方式来实现功能的良性扩展。
如下图：
2.3模板方法模式
模板方法模式定义了一个操作算法的股价，而将一些步骤延迟到了子类。模板方法模式使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。
2.4状态模式
状态模式允许对象在内部状态改变时候改变它的行为，对象看起来好像修改了它的类。
2.5策略模式
策略模式定义了一系列算法，并将它们分别封装了起来，让他们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。
3模式联合
3.1需求规格模式
需求规格模式属于企业架构模式，这个模式的使用方法就是：把业务规则放在业务类的外面，并且封装成为一个个bool值得算法。这个业务规则的算法不仅仅便于管理和维护，还可以被重用，而且可以很方便的组织成复杂的业务逻辑。
3.2组合模式
Composite模式让我们能够用树形方式创建对象的机构，树里面包含了组合以及个别的对象。使用组合结构，我们能把相同的操作应用在组合对象和个别对象上。
