业务逻辑层相关（文字信息版本）

主要介绍业务逻辑层的四种组织方式：

1.Transaction Script(事务脚本)：

面向过程式的组织方式，充斥着大量的业务方法，可能会出现好多重复的细粒度的API，使用比较简单，易于上手，但是项目过大，会暴露出其问题，不易扩展

2.Active Record(活动记录)：

该模式比较流行，尤其在底层数据库模型匹配业务模型时，通常，数据库中的每张表都对应一个业务对象。业务对象表示表中的一行，并且包含数据、行为以及持久化该对象的工具，此外还有添加新实例和查找对象集合所需的方法。

在Active Record模式中，每个业务对象均负责自己的持久化和相关的业务逻辑。

所以Active Record模式非常适合数据库模型和业务模型之间具有一对一映射关系的简单应用程序，如博客和论坛引擎，如果已经有数据库或者希望数据优先的方法来构建应用程序，这也是一个好用的模式，因为这种模式都有相同的增删查改操作，所有可以用代码生成器生成相应的代码，好的生成器甚至可以生成验证逻辑。

典型应用就是结合MVC模式+Active Record ORM

3.Anemic Model(贫血模型)：

有时候会被称为一种反模式，初看来，该模式和Domain Model模式有些类似，也会找到表示业务领域的领域对象，但是这些领域对象中，不包括任何的行为，这些行为位于领域之外，而让这些领域对象作为简单的数据传输类。

这种模式的不足之处在于，领域服务扮演更加过程式的角色，和Transaction Script模式有点像，这就违背了“讲述不要询问原则”，就是对象告诉客户他们能做什么或者不能做什么，而不是暴露属性让客户去决定某个对象是否处于执行给定动作所需要的状态。

4.Domain Model(领域模型)：

可以将Domain Model理解为将要处理的领域的概念模型，事物与事物之间的关系都存在在这个关系中，以电子商务网站为例，购物车、订单、订单项等类似的事物都为模型中的事物。这些事物包含数据，当然它们还有相应的行为，以及它所有的业务和领域规则。

Domain Model 越能表示真实的领域越好，这样就更容易理解和复制业务组织中的业务和规则以及验证过程。

Domain Model和Active Record之间的区别在于，Domain Model中的实体都不知道如何持久化自己，而且也没有必要在数据模型和实体模型建立一对一的映射关系。因为Domain Model不知道如何持久化自己，所以需要通过其他方式来做持久化操作，通常来说使用Repository模式，Repository对象负责业务实体的持久化工作。

通常其架构模式如下（依赖自下而上）：

Model层不会引用其他任何项目，从而确保让他和其他任何设施关注点保持隔离，只关注业务领域。

Repository层将包含Model层定义的IRepository资源接口的实现，该层引用了Model项目，从数据库提前并持久化领域对象，Repository对象只关注领域对象的持久化和检索。对于有些动作没有很好的映射到领域实体的方法，可以定义领域服务。试图在软件中解决复杂的业务逻辑非常困难，但使用Domain Model模式时，首先为真实的领域创建一个抽象的模型，有了这个模型之后，就可以对复杂的业务逻辑进行建模：追踪真实的领域并在领域模型中重建工作流和处理流程。与Transaction Script 以及Active Record模式相比，由于Domain Model模型中不包括访问数据库的代码，所以他可以很方便的进行单元测试。但是不足之处在于，如果对于逻辑较为简单的应用，使用便有大材小用的嫌疑了，而且为了精通该模式，需要面临陡峭的学习曲线，需要很多经验和时间上的积累才能很好的使用该模式，建模时还要全面了解整个领域对象的业务。

AppService是应用程序的门面（网关，API），UI层通过消息与AppService层通信，AppService层还将定义View Model，这些是领域模型的展开视图，只用于数据显示。协调应用程序活动，并将业务任务委托给Domain Model层，该层并不包含任何业务逻辑，该层还将领域实体转换成数据传输实体，从而保护领域的内部操作，并未一起工作的UI层，提供了易于使用的API。

UI层负责用户输入，属于前台用户展现层，只与AppService通信，并接受AppService专门为其创建的View Model。