编辑推荐

　　著译俱佳 ThoughtWorks资深咨询师倾力译、校
　　完整涵盖DDD各方面知识 提供大量示例代码
　　案例贯穿全书 理论与实践紧密衔接之典范
　　架构师、程序员境界提升不可或缺之必选书目
　　

内容简介

　　领域驱动设计（DDD）是教我们如何做好软件的，同时也是教我们如何使用面向对象技术的。它为我们提供了设计软件的全新视角，同时也给开发者留下了一大难题：如何将领域驱动设计付诸实践？Vaughn Vernon 的这本《实现领域驱动设计》为我们给出了全面的解答。

　　《实现领域驱动设计》分别从战略和战术层面详尽地讨论了如何实现DDD，其中包含了大量的实践、设计准则和对一些问题的折中性讨论。《实现领域驱动设计》共分为14 章，在DDD 战略部分，《实现领域驱动设计》向我们讲解了领域、限界上下文、上下文映射图和架构等内容，战术部分包括实体、值对象、领域服务、领域事件、聚合和资源库等内容。一个虚构的案例研究贯穿全书，这对于实例讲解DDD 实现来说非常有用。

　　《实现领域驱动设计》在DDD 的思想和实现之间建立起了一座桥梁，架构师和程序员均可阅读，同时也可以作为一本DDD 参考书。

作者简介

　　Vaughn Vernon，一个经验丰富的软件工匠，在软件设计、开发和架构方面拥有超过25年的从业经验。他提倡通过创新来简化软件的设计和实现。从20世纪80年代开始，他便开始使用面向对象语言进行编程；在 20世纪 90年代早期，他便在领域建模中应用了领域驱动设计，那时他使用的是Smalltalk语言。他在很多业务领域都有从业经验，包括航空、环境、地理、保险、医学和电信等领域。同时，Vaughn在技术上也取得了很大的成功，包括开发可重用的框架和类库等。他在全球范围之内提供软件咨询和演讲，此外，他还在许多国家教授《实现领域驱动设计》的课程。

精彩书评

　　★“在《实现领域驱动设计》中，Vaughn不仅为DDD领域做出了贡献，还为更宽阔的企业应用架构领域写上了厚重的一笔。例如，在架构和资源库等核心章节中，Vaughn向我们展示了如何将DDD与各种架构风格和持久化技术融合在一起——包括SOA、REST、NoSQL和数据网格等——其中很多都是在Eric Evans那本DDD开山之作出版之后才出现的。另外，书中还讲到了对实体、值对象、聚合、领域服务、事件、工厂和资源库的实现，其中包括大量的例子。一言以蔽之，我认为这本书非常全面。对于那些希望提升自己技能的软件开发者来说，《实现领域驱动设计》将是一本的好书。”
　　——Randy Stafford，自由架构师，Oracle Coherence产品部
　　
　　★“领域驱动设计是一套非常强大的思想工具，它深远地影响着软件开发团队的效率。问题在于，许多开发者在应用这套思想工具时会不时地迷失方向，他们需要更实际的指导建议。在本书中，Vaughn将理论与实践联系在了一起。除了为我们讲解那些易被误解的DDD概念之外，Vaughn还讲到了一些新的概念，比如命令/查询职责分离（CQRS）和事件源等。对于那些希望实际应用DDD的人来说，这是一本必读之作。”
　　——Udi Dahan，NServiceBus创始人
　　
　　★“多年以来， DDD的开发者们都希望获得一些更实际的帮助。 Vaughn缝合了理论和实践之间的间隙，向大家提供了一套完整的 DDD实现参考。他向我们展示了如何在当前软件项目中使用DDD，并且向我们提出了大量的实际建议。 “
　　——Alberto Brandolini，DDD导师（由 Eric Evans和Domain Language， Inc颁发证书）
　　
　　★“《实现领域驱动设计》清晰地向我们展示了 DDD的核心话题。本书的写作风格非常友好，就像一个值得信赖的导师在给你讲课一样。读完本书，你将能够应用 DDD的各个重要概念。我在阅读本书的时候，在很多章节中都做上了着重标记……我会经常地参考并推荐本书。”
　　——Paul Rayner，首席咨询师， DDD导师（由 Eric Evans和Domain Language， Inc颁发证书）， DDD Denver创始人。
　　
　　★“在我所教的 DDD课程中，很重要的一点便是如何将所有的 DDD理论付诸实践。有了本书， DDD社区便有了可供参考的资料。《实现领域驱动设计》包含了创建 DDD系统的方方面面，从具体的实现细节到高层的设计思想。这是一本了不起的 DDD参考书，同时也是 Eric Evans那本 DDD开山之作的伴侣。 “
　　——Patrik Fredriksson，DDD导师（由 Eric Evans和Domain Language， Inc颁发证书）
　　
　　★“如果你关心软件工艺——你也应该这么做——那么领域驱动设计便是非常重要的一项技能，而《实现领域驱动设计》则向我们提供了一条迈向成功的捷径。本书详尽地讨论了 DDD的战略模式和战术模式，使开发者能够立即将理论付诸实践。今后的业务软件系统将从本书中受益匪浅。”
　　——Dave Muirhead，首席咨询师， Blue River Systems 集团
　　
　　★“DDD既有理论，也有实践，这些都是每个开发者应该了解的，而本书则很好地弥补了理论与实践之间的差距。强烈推荐本书！ “
　　——Rickard Oberg，Java开发者， Neo Technology公司
　　
　　★“在《实现领域驱动设计》中， Vaughn采用了自顶向下的方法，首先讲到了 DDD的战略模式，比如限界上下文和上下文映射图，然后讲到了战术模式，比如实体、值对象和领域服务等。案例研究贯穿全书，要从中有所学，你需要在该案例研究上下足功夫。如果你这么做了，你便能看到将 DDD应用于复杂领域的意义所在。书中包含了大量的旁注、图标和示例代码。如果你希望使用当下常见的架构风格来创建一个 DDD系统，那么 Vaughn的这本《实现领域驱动设计》便是我所推荐的。”
　　——Dan Haywood，《Domain-Driven Design with Naked Objects》作者
　　
　　★“本书采用了一种自顶向下的方式来讲解 DDD，这种方式将 DDD的战略模式和战术模式自然地衔接起来。在本书中， Vaughn强调了业务领域的价值，同时也给出了技术上的讨论。因此， DDD在软件开发中的角色也变得非常清晰。很多时候，我的团队，包括我本人，在应用 DDD时都会遇到这样那样的麻烦。有了《实现领域驱动设计》的指导，我们得以克服种种挑战，进而将付出立即转化为业务价值。 “
　　——Lev Gorodinski，首席架构师， DrillSpot.com

目录

序
前言
致谢
关于作者
如何使用本书
第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章 聚合
在Scrum核心领域中使用聚合
第一次尝试：臃肿的聚合
第二次尝试：多个聚合
原则：在一致性边界之内建模真正的不变条件
原则：设计小聚合
不要相信每一个用例
原则：通过唯一标识引用其他聚合.
通过标识引用使多个聚合协同工作
建模对象导航性
可伸缩性和分布式
原则：在边界之外使用最终一致性.
谁的任务？
打破原则的理由
理由之一：方便用户界面
理由之二：缺乏技术机制
理由之三：全局事务
理由之四：查询性能
遵循原则
通过发现，深入理解
重新思考设计
估算聚合成本
常见用例场景
内存消耗
探索另外的设计
实现最终一致性
这是Scrum团队成员的任务吗？
决定的时候到了
实现
创建具有唯一标识的根实体
优先使用值对象
使用迪米特法则和“告诉而非询问”原则
乐观并发
避免依赖注入
本章小结

第11章 工厂
领域模型中的工厂
聚合根中的工厂方法
创建CalendarEntry实例
创建Discussion实例
领域服务中的工厂
本章小结

第12章 资源库
面向集合资源库
Hibernate实现
TopLink实现
面向持久化资源库
Coherence实现
MongoDB实现
额外的行为
管理事务
警告
类型层级
资源库 vs 数据访问对象（DAO）
测试资源库
以内存实现进行测试
本章小结

第13章 集成限界上下文
集成基础知识
分布式系统之间存在根本性区别
跨系统边界交换信息
通过REST资源集成限界上下文
实现REST资源
使用防腐层实现REST客户端
通过消息集成限界上下文
从Scrum的产品负责人和团队成员处得到持续通知
你能处理这样的职责吗？
长时处理过程，以及避免职责
长时处理过程的状态机和超时跟踪器
设计一个更复杂的长时处理过程
当消息机制或你的系统不可用时
本章小结

第14章 应用程序
用户界面
渲染领域对象
渲染数据传输对象
使用调停者发布聚合的内部状态
通过领域负载对象渲染聚合实例
聚合实例的状态展现
用例优化资源库查询
处理不同类型的客户端
渲染适配器以及处理用户编辑
应用服务
示例应用服务
解耦服务输出
组合多个限界上下文
基础设施
企业组件容器
本章小结
附录A 聚合与事件源：A+ES
应用服务内部
命令处理器
Lambda语法
并发控制
A+ES所带来的结构自由性
性能
实现事件存储
关系型持久化
BLOB持久化
专注的聚合
读模型投射
与聚合设计一道使用
增强事件
工具和模式
事件序列器
事件不变性
值对象
协议生成
单元测试和需求规范
事件源和函数式语言
参考文献

精彩书摘

　　当然，对于“当……的时候，请通知我”，这里的通知本身并不能构成一个事件，而只是表明我们需要向外界发出通知。另外，领域专家可能还会说“如果发生这样的事情，它并不重要；如果发生那样的事情，它就很重要了（将“这样”和“那样”用你自己领域中的事件予以替换）。”根据你的组织文化，可能还有更多的事件用语。
　　牛仔的逻辑
　　有时，从领域专家的话中，我们看不出领域事件的迹象，但是业务需求依然有可能需要领域事件。领域专家有可能意识不到这些需求，只有在跨团队讨论之后他们才能意识到这些。发生这样的事情往往是由于领域事件需要发布到外部系统中，比如发布到另一个限界上下文中（2）。由于这样的事件由订阅方处理，它将对本地和远程上下文产生深远的影响。
　　领域专家和领域事件
　　虽然领域专家在起初可能意识不到所有类型的领域事件，但是通过讨论之后，他们是应该能够了解到其中的原因的。当团队成员对领域事件达成一致之后，领域事件便是通用语言的正式组成部分了。
　　当领域事件到达目的地之后一一无论是本地系统还是外部系统一一我们通常都将领域事件用于维护事件的一致性。这是有意而为之的，并且是根据设计而来的。这样可以消除两阶段提交（全局事务），还可以支持聚合（10）原则。聚合的其中一个原则是，在单个事务中，只允许对一个聚合实例进行修改，由此产生的其他改蛮必须存单独的事务中完成。

　　……

前言/序言

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

实惠，送货快，赞一个。

2016年11.11号我在JD抢到了一个199的机器人，JD发货没联系到买家，在没经过买家的同意，自行把订单取消，发货花了一个星期，取消订单却只花了一分钟，客服就像傻子一样，听不懂人话。以后都不要在JD上买。

在20%的时间里挣到的，所以要把最重要、分数最多的章节，放在第一时间搞透彻。

；没有分的，坚决不看、不问、不琢磨、不围观。还要记得二八法则，80%的分数，一定是你在20%的时间里挣到的，所以要把最重要、分数最多的章节，放在第一时间搞透彻。

买了一本《实现领域驱动设计》的书籍，连一层塑料膜包装都没有的，整本书看起来就是二手退货，看起来很破旧，真是失望！

无塑封，外观有损伤。两颗星给看起来是正版的书质

东西不错，物流很快，赞一个

好好好，不错不错，可以可以。好好好，不错不错，可以可以。好好好，不错不错，可以可以。

很好 很好 很好