实现领域驱动设计--各章概要-原文

原文：

第一章：DDD入门
本章向你介绍DDD的好处，并且教你如何尽可能多地去实现DDD。你将学到当你应对复杂的软件系统时，DDD可以为你的项目和团队带来什么。同时，你将了解到同行的DDD替代方案以及这些方案为什么会导致问题，作为对DDD的基础讲解，本章将教你如何在项目中开始采用DDD，还有如何想你的领域专家和技术团队推销DDD。在DDD的武装下，你将学会如何迎战挑战，勇往直前。
本章将介绍关于一个公司及其团队的案例研究。虽然该公司是虚构的，但是他们所面临的DDD挑战却是真实存在的，该公司旨(zhi)在开发一个新的多租户SaaS（Software as a Service,软件即服务）软件产品。不出所料，在使用DDD时，他们翻了一些常见的错误。不过还好，他们发现了这些错误，并解决了一些问题，因此项目还算没有偏离正轨。该团队需要开发一套基于Scrum的项目管理软件。该案例还会在本书的后续章节中连续讲到。每一种战略和战术模式都将向着成功的DDD实践昂首阔步。

第二章：领域、子域和限界上下文
领域、子域和核心域分别是什么？限界上下文是什么，我们为什么要使用它，摒弃如何使用？这些问题将在这个SaaS项目团队犯错误的时候给予解答。在他们的第一个DDD项目中，他们并不了解子域、限界上下文和通用语言这些概念。事实上，他们根本不知道什么是战略设计，只是采用了战术设计来解决一些技术上的问题。这样他们在开始设计领域魔性的时候便遇到了不少问题。幸运的是，他们及时地意识到了这些问题，项目还有挽回的余地。 本章还讲到了如何使用限界上下文对模型进行分离，这是非常重要的；同时还讲到了一些模型分离不当的反例，并且给出了有效的实现建议，在采用了这些建议之后，该团队的成员们重新创建了两个不同的限界上下文。这种合理的模型分离带来的好处四引出了第三个限界上下文，核心域，这像是本书使用的主要例子。 对于那些苦于单单从技术层面应用DDD的人来说，本章应该能引起你的共鸣。如果你还是DDD战略设计的外行，那么本章将为你指明方向。

第三章：上下文映射图
上下文映射图帮助我嫩理解业务领域、模型间的边界，以及这些模型之间的集成方式。
上下文映射图绝对不只是绘制系统架构图这么简单，他处理的不同限界上下文之间的关系，以及如何在不同的模型之间映射对象。对于在复杂的业务系统中国呢使用好限界上下文，这是至关重要的。在第二章中，团队成员们在首次尝试限界上下文时碰到了问题。本章中，他们将学者如何利用上下文映射图来解决这些问题。这样的结果是产生了两个体面地限界上下文，这两个上下文将被另外一个负责核心域的团队所使用。

第四章：架构
我们都知道分层架构（contoller、service、dao），但它是开发DDD软件的唯一方式吗，也或许还存在另外的方式？在本章中，我们将讲到：六边形架构（端口和适配器）、面向服务架构、REST、CQRS(命令与查询分离)、事件驱动(管道和过滤器，长时处理过程、事件源)和数据网格，其中好几种架构都将被该团队成员所采用。

第五章：实体
在DDD的战术模式中，我们将首先讲到实体。团队成员们一开始过于强调实体的作用而忽视了只对象。收到数据库和持久化框架的影响，实体被该团队滥用了，此时他们开始讨论如何避免大范围地使用实体。
在本章中，你将看到很多优秀的实体设计例子。同时，本章还将讲到如何使用实体来表达通用语言，以及如何对实体进行测试、实现和持久化。

第六章：值对象
早些时候，团队成员们错过了采用只对象的好机会。他们过于注重为实体创建一些单一属性，这种方式是欠妥的，更好的方式是将这些单一的属性聚合成一个不变的整体。本章将从不同的角度讲解如何设计值对象，以及在什么时候采用只对象会优于实体。同时，本章还包含了一些其他话题，比如值对象在集成中的角色和对标准类型的建模等。此外，本章还讲到了在聚合中存储值对象时，如何避免持久化机制所带来的不利影响。

第七章：领域服务
本章将讲到，在领域魔性中，什么时候应该讲一个概念建模成力度适中，并且无状态的领域服务。你将学会到何时应该使用领域服务而不是实体或者值对象，以及如何使用领域服务来处理业务逻辑和技术上的集成。团队成员们向我们展示了何时应该使用领域服务，以及如何设计领域服务。

第八章：领域事件
Eric Evans并没有在他的书中正式介绍领事件，领域事件是在他那本书出版之后才进入人们视野的。在本章中，你将学到为什么领域事件如此有用，以及使用领域事件的不同方法。领域事件甚至被用来辅助集成和自治性服务。在软件系统中，我们经常使用一些技术层面的事件机制，但本章将着重讲解领域事件与这些事件机制的区别。本章还讲知道你如何设计并实现领域事件，包括一些可行的方案和对这些方案的权衡选择。然后，本章将讲到如何创建一个发布-订阅机制；如何创建和管理事件存储；如何处理消息机制所面临的常见挑战等。

第九章：模块
对于模型中的对象，我们应该如何将他们组织在大小适中的容器中呢？我们又如何保证 不同容器中的对象之间只存在有限的耦合？另外，我们如何对这些容器进行命名以提现通用语言？除了包和命名空间之外，我们如何使用由语言和框架提供的现代模块化机制，比如OSGI和Jigsaw？在本章中，你将看到SaaS团队成员是如何在不同的项目中使用模块的。

第十章：聚合
在DDD的战术模式中，聚合可能是最不容易理解的了。然而，在遵循一定的经验法则的情况下，我们是能够更简单、更快地实现聚合。在本章中你将学到：如何利用聚合在不用的小规模对象集群间创建一致性边界，从而降低模型的复杂性。由于在细枝末节上花了太多精力，SaaS团队成员们在设计聚合时总是磕磕绊绊。我们将仔细研究该团队所面临的挑战，并且分析错误的原因以及他们的应对策略。结果，团队成员们对他们的核心域有了更深层次的理解。我们将看到，在合理的事务处理和最终一致性（Eventual Consistency）的前提下，该团队更正了他们所发的错误，并且在一个分布式环境中设计出了更具有伸缩性和更高效的模型。

第十一章：工厂
工厂已经在【Gammaetal】中被大量的太急了，为什么还要讲呢？本章并不打算重蹈覆辙，而是将重点放在“工厂应该存在于何处”这个问题上。在本章中，我们将讲到在DDD中实现工厂的技巧。团队成员在他们的核心域中创建的工厂可以简化客户端接口，并且对模型的消费方起到了保护作用，从而避免可在多租户环境中引入在灾难性的bug.

第十二章：资源库
资源库只是一个数据访问对象（Data Accesss Object,DAO）吗？如果不是，他们之间有什么区别呢？我们为什么应该将资源库堪称是对集合的模拟而非数据库呢？在本章中，我们将讲解到如何利用ORM来实现资源库，其中两种ORM方案，一种采用基于网络的分布式缓存，另一种则采用NoSql的键值对存储/团队成员们可以采用任何一种作为他们的持久化机制。

第十三章：集成限界上下文
到现在为止，你已经了解了战略层次的上下文映射图和多种战术层次的模式。本章将讲到，在DDD中吗，我们如何通过上下文映射图来集成不同的模型。在团队对核心域和其他辅助型的限界上下文进行集成时，我们将给出乡音的建议和指导。

第十四章：应用程序
对于每一个核心域的通用语言，我们都设计了相应的模型，并且进行了足够的测试，模型工作正常。然而，客户应该如何使用我们的模型呢？他们应该使用DTO将数据在模型和用户界面之间传输吗？或者存在其他方案可以实现模型和展现组件间的数据传递？DDD中的应用服务和基础设施是如何工作的？对于这些问题，本章都将做出解答。