本章只是简单地介绍了DDD，在案例研究中还将复习，届时还将介绍用户的故事，以方便构建需求并理解正在处理的领域。为了更深入地研究该方法学，推荐阅读下面这两本著作：

●  Domain-Driven Design: Tackling Complexity in the Heart of Software(Addison-Wesley，2003)，Eric Evans著

●  Applying Domain-Driven Design and Patterns: Using .Net With Examples in C# and .NET (Addison-Wesley，2006)，Jimmy Nilsson著

4.2  小结

本章介绍了一些流行的、经过验证的业务逻辑组织模式。下面是主要的4种方法。

●  Transaction Script：如果应用程序较小，业务逻辑很少甚至没有业务逻辑，则Transaction Script模式就是建立简单解决方案的很好选择，接手代码的开发人员容易理解它。

●  Active Record：如果业务层只是位于数据库之上的一个瘦层，则Active Record是很好的模式选择。有许多代码生成工具能够自动根据数据库模式创建业务对象，而且手工创建这些对象也并非难事。

●  Domain Model：Domain Model非常适于为棘手的、丰富的、复杂的业务领域建模。它是一种涉及创建真实业务领域抽象模型的纯粹的面向对象方法，在处理复杂逻辑和工作流时非常有用。领域模型是持久化透明的，它依靠映射器类和Repository模式来持久化和检索业务实体。

●  Anemic Model：Anemic Model模式是Domain Model的反模式。粗略一看它们一样，但进一步研究之后发现，表示正在建模领域的领域对象只是没有行为的数据传输对象。领域的逻辑被放在过程式方法中来验证或检查对象的状态，这违背了第1章中讨论的“讲述而不要询问”原则。

在学习了组织业务逻辑层的4种主要方法之后，介绍了DDD(领域驱动设计)设计方法学，它利用领域模型以服务、实体、值对象和聚合的形式来表示复杂逻辑。DDD还鼓励人们关注业务逻辑和正在建模的领域，它运用POCO或PI原则来确保不让基础设施关注点污染纯粹的业务领域模型。

本章介绍了如何将DDD的概念和构造块应用到银行账号应用程序中，同时也展示了它们如何能够让我们为正在工作的领域建立清晰的模型，无需关注任何基础设施关注点，而在项目、类和方法名称上，应用程序使用的语言与领域所用语言相同。在第10章和第11章的案例研究中，将介绍如何使用更大型的、更复杂的领域，通过遵循DDD原则，将它们很容易地映射到复杂的工作流和业务事务。

第5章将考察能够用于企业应用程序的业务层中的模式和原则。