本章内容要点：
1.Transaction Script模式组织业务逻辑
2.Active Record模式和Castle Windsor来组织业务逻辑
3.Domain Model模式来组织业务逻辑
4.Anemic Model模式和Domain Model 来组织业务逻辑的差异
5.理解领域驱动设计DDD以及如何运用它让自己专注于业务逻辑而不是基础设施关注点
并非所有的应用程序都是一样的，也并非所有的应用程序都需要复杂的体系结构来封装系统的业务逻辑。作为开发者，重要的是要理解所有领域逻辑模式的优缺点，这样才能设计出最合适的模式。
Transaction Script
这个我就不费过多的口舌了。完全是面向过程式的写法。所以是最容易理解，掌握和运用的模式。通常的做法是为每隔业务事务创建一个单独的方法，并将它们组合起来放入某种静态管理程序或服务类。每个过程都包含了完成业务事务所需要的所有的业务逻辑，包括工作流，业务规则和数据库持久化验证检查。
其优势是容易理解并上手。
其劣势是一旦程序变大或者业务逻辑变得复杂时，方法的数目变多，从而形成一个充斥着功能交叠的细粒度方法的无用API。代码将会很快变得笨重且不可维护。
由于这种方式比较简单，我们无须给出示例。
Active Record
Active Record模式是一种流行的模式，尤其在底层数据库模型匹配业务模型时，它特别有效。通常，数据库中的每张表都对应一个业务对象。业务对象表示表中的一行，并且包含数据、行为以及持久化该对象的工具，此外还有添加新实例和查找对象集合所需的方法。
在Active Record模式中，每隔业务对象均负责自己的持久化和相关的业务逻辑。
Active Record模式非常适用于在数据模型和业务模型之间具有一对一映射关系的简单应用程序，如博客或论坛引擎。如果已经有数据库模型或者希望采用“数据优先”的方法来构建应用程序，这也是一个可用的好模式。因为业务对象与数据库中的表具有一对一映射关系，而且均具有相同的创建，读取，更新和删除方法，所以可以使用代码生成工具自动生成业务模型。与Transaction Script模式一样，Active Record模式也非常简单并且易于掌握。
Active Record模式随着基于数据库的Web应用程序而流行，其中一个典型就是结合了MVC模式和Active Record ORM的Ruby on Rails框架。在.net领域，构建在NHibernate之上的Castle ActiveRecord项目是最流行的开放源代码Active Record框架之一。以下将通过构建一个简单的博客网站（博客网站只包含少量的业务逻辑，因此在业务对象和数据模型之间存在较好的相关性），来展示其具体用法。
