第二章：管理领域逻辑

三个主要的模式：Transaction Script，Domain Model，Table Model

最简单的方法是使用Transaction Script,Transaction Script本质上就是从表现层接受输入，进行验证和计算，保存进数据库，调用其他外部操作并且返回更多的信息，帮助计算并组织数据给表现层的过程。基本上就是将用户可能做的事情组织成一个个的函数，所以可以将其想象成动作的脚本，或者一个个事务。

Transaction Script的优势：

• 是几乎每个开发者都了解的简单的过程模式
• 配合使用简单的数据库层模式，如Row Data Gateway，Table Data Gateway时工作的很好
• 非常明显的边界:以打开事务开始，关闭事务结束。

但是，在领域逻辑变得越来越复杂时，Transaction Script也会有很多劣势，会出现很多难以消除的重复代码，子方法越来越多后，缺乏清晰的结构。

这个时候，就该以面向对象方式处理逻辑的Domain Model模式登场了。我们主要围绕着领域中的名词来建立Domain Model模式，验证和计算的逻辑会放在Domain Model中。与Transaction Script将所有逻辑放在一个函数里不同，在Domain Model中，每个对象只负责自己相关的那一部分逻辑。Domain Model的价值是一旦你掌握了它，它提供了很多种管理不断增长的复杂逻辑的方法，如增加不同的策略对象。Domain Model的复杂性来源于使用上的复杂（新手需要学习的时间，思维的转换）以及数据源层的复杂（领域逻辑越复杂，数据库映射也越复杂）。

第三种选择是使用Table Model模式。Table Model模式适合与Record Set一起使用。Table Model看起来像是上面两者的一个折中，围绕着数据表来组织领域逻辑比起Transaction Script来说更为结构化，也更容易找出并排除重复代码，并且可以使用Domain Model中用来得到更好的结构的方法，如继承，策略等OO的模式。最大的好处就是它可以和系统的其他部分很好的进行配合，很多GUI的环境都建立在SQL查询的结果之上，这些结果通常用Record Set保存（如.NET中的数据绑定），而Table Model也是在Record Set上工作的。

做出抉择

对于简单的领域逻辑，Domain Model没什么吸引力，因为理解它的成本和数据源层点的成本显得太高了，然而，随着领域逻辑的复杂性的增加，其他的几个模式的成本程指数上升，而Domain Model是线性上升的。

对Domain Model熟悉的开发团队可以降低初始的成本，但不会降到和其他两个一样低，因为它的数据源层比较复杂。

Table Model吸引力的强弱很大程度上取决于你使用的开发环境对Record Set基本架构的支持程度，如.NET就支持非常好。

这三种模式并不是排他的，事实上，混合使用的情况是很常见的。

服务层（Service Layer）

常见的管理领域逻辑的方法是将它分成两层。服务层建立在Domain Model或Table Model之上，Transaction Script因为太简单了而不需要服务层。表现层完全通过服务层与领域层交互，这使它显得像是一组API。

服务层也是放置事务管理，安全管理的好地方。通常使用文件来配置这些信息，但是在.NET中使用自定义熟悉也是一个非常好的方法。

当你想到服务层的时候，一个关键的问题是在里面放多少的逻辑。最少的情况下，服务层就是一个facade模式的体现，提供了一组易于使用的API，并可以提供了事务管理和安全管理。另一个极端的情况下，大部分的逻辑都放置在服务层中，下次的领域对象非常的简单，如果下层是Domain Model，你将可以使用一个简单的数据源层，如Active Record。两者的折中，controller-entity，这里的关键点是将特定的事务或者用例放到Transaction Script中（通常将其称为controller，注意controller有很多种，如后面会说到的Model View Controller和Application Controller），这里作者将其称为user-case controller，相对于那些用于多个用例的方法，它们在领域对象中，称为entities。

作者建议，如果需要的话，就使用一个最“瘦”的服务层。