实现领域驱动设计

内容简介

领域驱动设计（DDD）是教我们如何做好软件的，同时也是教我们如何更好地使用面向对象技术的。它为我们提供了设计软件的全新视角，同时也给开发者留下了一大难题：如何将领域驱动设计付诸实践？Vaughn Vernon 的这本《实现领域驱动设计》为我们给出了全面的解答。
　　《实现领域驱动设计》分别从战略和战术层面详尽地讨论了如何实现DDD，其中包含了大量的实践、设计准则和对一些问题的折中性讨论。《实现领域驱动设计》共分为14 章，在DDD 战略部分，《实现领域驱动设计》向我们讲解了领域、限界上下文、上下文映射图和架构等内容，战术部分包括实体、值对象、领域服务、领域事件、聚合和资源库等内容。一个虚构的案例研究贯穿全书，这对于实例讲解DDD 实现来说有用。
　　《实现领域驱动设计》在DDD 的思想和实现之间建立起了一座桥梁，架构师和程序员均可阅读，同时也可以作为一本DDD 参考书。

目录

序 xix
前言 xxi
致谢 xxxi
关于作者 xxxv
如何使用本书xxxvii
第1章 DDD入门
我能DDD吗？
为什么我们需要DDD
如何DDD
使用DDD的业务价值
1你获得了一个有用的领域模型
2你的业务得到了更准确的定义和理解
3领域专家可以为软件设计做出贡献
4更好的用户体验
5清晰的模型边界
6更好的企业架构
7敏捷、迭代式和持续建模
8使用战略和战术新工具
实施DDD所面临的挑战
虚构的案例，真实的实践
本章小结
第2章 领域、子域和限界上下文
总览
工作中的子域和限界上下文
将关注点放在核心域上
战略设计为什么重要
现实世界中领域和子域
理解限界上下文
限界上下文不仅仅只包含模型
限界上下文的大小
与技术组件保持一致
示例上下文
协作上下文
身份与访问上下文
敏捷项目管理上下文
本章小结
第3章 上下文映射图
上下文映射图为什么重要
绘制上下文映射图
产品和组织关系
映射3个示例限界上下文
本章小结
第4章 架构
采访一个成功的CIO
分层
依赖倒置原则
六边形架构（端口与适配器）
面向服务架构
REST
REST作为一种架构风格
RESTful HTTP服务器的关键方面 
RESTful HTTP客户端的关键方面 
REST和DDD
为什么是REST？
命令和查询职责分离——CQRS
CQRS的各个方面
处理具有一致性的查询模型
事件驱动架构
管道和过滤器
长时处理过程（也叫Saga）
事件源
数据网织和基于网格的分布式计算
数据复制
事件驱动网织和领域事件
持续查询
分布式处理
本章小结
第5章 实体
为什么使用实体
标识
用户提供标识
应用程序生成标识
持久化机制生成标识
另一个限界上下文提供标识
标识生成时间
委派标识
标识稳定性
发现实体及其本质特征
揭开实体及其本质特征的神秘面纱
挖掘实体的关键行为
角色和职责
创建实体
验证
跟踪变化
本章小结
第6章 值对象
值对象的特征
度量或描述
不变性
概念整体
可替换性
值对象相等性
无副作用行为
化集成
用值对象表示标准类型
测试值对象
实现
持久化值对象
拒绝由数据建模泄漏带来的不利影响
ORM与单个值对象
多个值对象序列化到单个列中
使用数据库实体保存多个值对象
使用联合表保存多个值对象
ORM与枚举状态对象
本章小结
第7章 领域服务
什么是领域服务（先，什么不是领域服务）
请确定你是否需要一个领域服务
建模领域服务
独立接口有必要吗
一个计算过程
转换服务
为领域服务创建一个迷你层
测试领域服务
本章小结
第8章 领域事件
何时/为什么使用领域事件
建模领域事件
创建具有聚合特征的领域事件
身份标识
从领域模型中发布领域事件
发送方
订阅方
向远程限界上下文发布领域事件
消息设施的一致性
自治服务和系统
容许时延
事件存储
转发存储事件的架构风格
以REST资源的方式发布事件通知
通过消息中间件发布事件通知
实现
发布NotificationLog
发布基于消息的事件通知
本章小结
第9章 模块
通过模块完成设计
模块的基本命名规范
领域模型的命名规范
敏捷项目管理上下文中的模块
其他层中的模块
先考虑模块，再是限界上下文
本章小结
第10章 聚合
在

摘要与插图

所有的计算都表明它不工作，的做法是：使其工作。 ——Pierre-Georges Latécoère早期法国航空企业家
　　是的，我们将使其工作。然而，在软件开发过程中采用领域驱动设计却是困难的。即便是有能力的开发者，也很难找到实现领域驱动设计的正确方法。
　　起飞，着陆
　　在我小的时候，我的父亲学习过驾驶小型飞机。我们经常会全家出去飞行，有时会飞到另一个机场，在那里吃过午饭后再返回。当父亲时间有限而他依然想飞时，父亲便带上我一起在机场上空盘旋，起飞，着陆，再起飞，再着陆。
　　也会有些长途飞行，这时我们会带上一张由父亲先前绘制好的路线图。我们几个小孩便当起了领航员：将图上的标志对应着陆地上的地标，以确保我们没有跑偏航线。这是一件很有趣的事情，因为要识别远在地面上的物体是很有挑战性的。事实上，我敢肯定父亲根本不用我们领航便知道我们处于什么方位——他能看到仪表盘上的所有信息，并且他拥有仪表飞行执照。
　　空中的景观的确改变了我的视野。不时地，父亲和我会飞过我们乡下的房子。在几百英尺的高空中，我体会到了另一种“家”的概念，而这在之前是没有过的。当我们飞过自家的房子时，母亲和我的姐妹们便会跑到院子里向我们挥手。我知道那是她们，即便我看不清楚她们是谁。谈话肯定是不行的，连大声喊都不行，她们是听不见的。我还可以看到将我家和外面公路分开的护栏，平时我们会像走平衡木一样在护栏上面走来走去。从空中看，它们就像被细心编排过的小树枝一样。我们
　　家的院子很大，每每到了夏天，我都会开着割草机一排一排地修理院子里的草坪。而在空中时，我只能看到一片绿色，小草的叶子肯定是看不清楚的。
　　我喜欢在空中的时刻，直到现在我还不时回想起这些时刻，好像那个降落飞
　　机的黄昏就发生在不久以前一样。虽然如此，在地面上的感觉依然是无法取代的，
　　因为它给我一种脚踏实地的感觉。
　　着陆于领域驱动设计
　　一开始接触领域驱动设计（ DDD）就像一个小孩之于飞行一样。天空中的景色是令人惊叹的，但有时我们却因为过于陌生而搞不明白它们到底是什么。要从甲地到乙地显得如此的遥远。然而， DDD的“成年人 ”们却总知道他们所处的方位，因为他们在很早之前便绘制好了路线图，并且能够按照仪表进行相应的操作。而还有很多人找不到“在地面上”的感觉，此时我们需要的是“稳定着陆”的能力，然后找到一张地图给我们指引方向。
　　Eric Evans的《领域驱动设计：软件核心复杂性应对之道》是一本经得住时间考验的经典之作。我坚定地相信，在接下来的几十年里，本书依然会是开发者的实用指导。和其他模式一样，该书为我们建立起了一种高屋建瓴式的宽阔视野。然而，对于如何实现 DDD，我们可能将面对更多的挑战。通常来说，我们更渴望看到一些具体的例子。
　　我的目标之一便是帮助你来一个“软着陆”，保全飞机，然后沿着一条周知的线路带你回家。这将帮助你如何更好地去实现 DDD，并且通过你所熟悉的工具和技术给出示例演示。当然，任何一个人都不可能一直呆在家里，所以我还会带领你到新的地带去冒险，这些地带你可能从来没有去过。冒险之路是险峻的，但是在正确的战术应对下，征服这些困难是可能的。在这条冒险之路上，你将学到另外的架构和模式来集成多个领域模型。你将接触到先前没有被研究过的集成方法，并且学到如何开发自治性服务。
　　我将向你提供一张对短途旅行和长途旅行均适用的地图，它可以帮助你更好地享受沿途风景，同时又不至于迷失途中。
　　对照地形，绘制飞行图
　　在软件开发的过程中，我们经常做的一件事便是将一种