实现领域驱动设计DDD战略设计复杂领域软件项目开发企业应用架构模式教程书籍系统化方法籍pdf下载pdf下载

实现领域驱动设计DDD战略设计复杂领域软件项目开发企业应用架构模式教程书籍系统化方法籍百度网盘pdf下载

作者:
简介:本篇主要提供实现领域驱动设计DDD战略设计复杂领域软件项目开发企业应用架构模式教程书籍系统化方法籍pdf下载
出版社：润知天下图书专营店
出版时间：
pdf下载价格：0.00￥

免费下载

前去下载

书籍下载

下载地址

内容介绍



商品参数


  商品基本信息,请以下列介绍为准
图书名称： 实现领域驱动设计
作者： Vaughn Vernon（沃恩.弗农）
定价： 128.00
ISBN号： 9787121224485
出版社： 电子工业出版社


  编辑推荐

著译俱佳 ThoughtWorks资深咨询师倾力译校

完整涵盖DDD各方面知识 提供大量示例代码

案例贯穿全书 理论与实践紧密衔接之典范

架构师、程序员境界提升不可或缺之必选书目


  内容简介

领域驱动设计（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章 聚合 
在Scrum核心领域中使用聚合 
diyi次尝试：臃肿的聚合 
第二次尝试：多个聚合 
原则：在一致性边界之内建模真正的不变条件
原则：设计小聚合 
不要相信每一个用例 
原则：通过唯一标识引用其他聚合 
通过标识引用使多个聚合协同工作 
建模对象导航性 
可伸缩性和分布式 
原则：在边界之外使用最终一致性 
谁的任务？ 
打破原则的理由 
理由之一：方便用户界面 
理由之二：缺乏技术机制 
理由之三：全局事务 
理由之四：查询性能 
遵循原则 
通过发现，深入理解 
重新思考设计 
估算聚合成本 
常见用例场景 
内存消耗 
探索另外的设计 
实现最终一致性 
这是Scrum团队成员的任务吗？ 
决定的时候到了 
实现 
创建具有唯一标识的根实体 
优先使用值对象 
使用迪米特法则和“告诉而非询问”原则 
乐观并发
避免依赖注入
本章小结 
第11章 工厂 
领域模型中的工厂 
聚合根中的工厂方法 
创建CalendarEntry实例 
创建Discussion实例 
领域服务中的工厂 
本章小结 
第12章 资源库
面向集合资源库
Hibernate实现 
TopLink实现 
面向持久化资源库 
Coherence实现 
MongoDB实现 
额外的行为 
管理事务 
警告 
类型层级 
资源库 vs 数据访问对象（DAO）
测试资源库 
以内存实现进行测试
本章小结
第13章 集成限界上下文
集成基础知识
分布式系统之间存在根本性区别
跨系统边界交换信息
通过REST资源集成限界上下文 
实现REST资源 
使用防腐层实现REST客户端 
通过消息集成限界上下文 
从Scrum的产品负责人和团队成员处得到持续通知 
你能处理这样的职责吗？ 
长时处理过程，以及避免职责 
长时处理过程的状态机和超时跟踪器 
设计一个更复杂的长时处理过程 
当消息机制或你的系统不可用时 
本章小结
第14章 应用程序
用户界面
渲染领域对象 
渲染数据传输对象 
使用调停者发布聚合的内部状态 
通过领域负载对象渲染聚合实例 
聚合实例的状态展现 
用例优化资源库查询 
处理不同类型的客户端 
渲染适配器以及处理用户编辑 
应用服务 
示例应用服务 
解耦服务输出 
组合多个限界上下文 
基础设施 
企业组件容器 
本章小结 
附录A 聚合与事件源：A ES 
应用服务内部 
命令处理器 
Lambda语法
并发控制 
A ES所带来的结构自由性 
性能 
实现事件存储 
关系型持久化 
BLOB持久化 
专注的聚合 
读模型投射 
与聚合设计一道使用 
增强事件 
工具和模式 
事件序列器 
事件不变性 
值对象 
协议生成 
单元测试和需求规范 
事件源和函数式语言 
参考文献


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


  精彩试读
所有的计算都表明它不工作，唯一的做法是：使其工作。 ——Pierre-Georges Latécoère早期法国航空企业家
是的，我们将使其工作。然而，在软件开发过程中采用领域驱动设计却是困难的。即便是有能力的开发者，也很难找到实现领域驱动设计的正确方法。
起飞，着陆
在我小的时候，我的父亲学习过驾驶小型飞机。我们经常会全家出去飞行，有时会飞到另一个机场，在那里吃过午饭后再返回。当父亲时间有限而他依然想飞时，父亲便带上我一起在机场上空盘旋，起飞，着陆，再起飞，再着陆。
也会有些长途飞行，这时我们会带上一张由父亲先前绘制好的路线图。我们几个小孩便当起了领航员：将图上的标志对应着陆地上的地标，以确保我们没有跑偏航线。这是一件很有趣的事情，因为要识别远在地面上的物体是很有挑战性的。事实上，我敢肯定父亲根本不用我们领航便知道我们处于什么方位——他能看到仪表盘上的所有信息，并且他拥有仪表飞行执照。
空中的景观的确改变了我的视野。不时地，父亲和我会飞过我们乡下的房子。在几百英尺的高空中，我体会到了另一种“家”的概念，而这在之前是没有过的。当我们飞过自家的房子时，母亲和我的姐妹们便会跑到院子里向我们挥手。我知道那是她们，即便我看不清楚她们是谁。谈话肯定是不行的，连大声喊都不行，她们是听不见的。我还可以看到将我家和外面公路分开的护栏，平时我们会像走平衡木一样在护栏上面走来走去。从空中看，它们就像被细心编排过的小树枝一样。我们
家的院子很大，每每到了夏天，我都会开着割草机一排一排地修理院子里的草坪。而在空中时，我只能看到一片绿色，小草的叶子肯定是看不清楚的。
我喜欢在空中的时刻，直到现在我还不时回想起这些时刻，好像那个降落飞
机的黄昏就发生在不久以前一样。虽然如此，在地面上的感觉依然是无法取代的，
因为它给我一种脚踏实地的感觉。
着陆于领域驱动设计
一开始接触领域驱动设计（ DDD）就像一个小孩之于飞行一样。天空中的景色是令人惊叹的，但有时我们却因为过于陌生而搞不明白它们到底是什么。要从甲地到乙地显得如此的遥远。然而， DDD的“成年人 ”们却总知道他们所处的方位，因为他们在很早之前便绘制好了路线图，并且能够完全按照仪表进行相应的操作。而还有很多人找不到“在地面上”的感觉，此时我们需要的是“稳定着陆”的能力，然后找到一张地图给我们指引方向。 
Eric Evans的《领域驱动设计：软件核心复杂性应对之道》是一本经得住时间考验的经典之作。我坚定地相信，在接下来的几十年里，本书依然会是开发者的实用指导。和其他模式一样，该书为我们建立起了一种高屋建瓴式的宽阔视野。然而，对于如何实现 DDD，我们可能将面对更多的挑战。通常来说，我们更渴望看到一些具体的例子。
我的目标之一便是帮助你来一个“软着陆”，保全飞机，然后沿着一条周知的线路带你回家。这将帮助你如何更好地去实现 DDD，并且通过你所熟悉的工具和技术给出示例演示。当然，任何一个人都不可能一直呆在家里，所以我还会带领你到新的地带去冒险，这些地带你可能从来没有去过。冒险之路是险峻的，但是在正确的战术应对下，征服这些困难是可能的。在这条冒险之路上，你将学到另外的架构和模式来集成多个领域模型。你将接触到先前没有被研究过的集成方法，并且学到如何开发自治性服务。
我将向你提供一张对短途旅行和长途旅行均适用的地图，它可以帮助你更好地享受沿途风景，同时又不至于迷失途中。
对照地形，绘制飞行图
在软件开发的过程中，我们经常做的一件事便是将一种东西映射到另一种东西。我们将对象映射到数据库，映射到用户界面，或者映射到不同的应用层展现（包括作为消费方的其他系统或应用程序）。在所有这些映射中，我们很自然地希望在Evans提出的高层模式和具体实现之间存在一种映射。
即便你已经接触过 DDD，你依然有很多可以获益的地方。有时， DDD首先被看作是一套技术工具集，有人将此称为 DDD-Lite。我们可能已经对实体、服务等 DDD概念非常熟悉了，并且大胆地尝试着设计聚合，还通过资源库来管理持久化。这些模式是大家相对熟知的，使用起来很容易，我们甚至还使用了值对象。以上这些都属于战术设计模式范畴，也即更加偏向技术层面。这些模式可以很好地帮我们解决软件问题。而同时，对于战术性模式，我们依然有许多需要学习的。我将战术模式映射到实现层面。
你曾了解过战术建模之外的东西吗？你曾了解过被称为 DDD“另一半”的战略设计模式吗？如果你还没有使用过限界上下文和上下文映射图，那么你很有可能也没有使用过通用语言。
如果说 Evans在软件开发社区有一项发明，那便是通用语言。通用语言是一种团队协作模式，用于捕捉特定业务领域中的概念和术语。一个特定领域的软件模型通过不同的名词、形容词和动词来表达，这些词汇是开发团队正式使用的，而团队中应该包含一个或多个领域专家。然而，将通用语言仅限定于一些词汇则是错误的。就像自然语言反映人们的思想一样， DDD的通用语言反映了领域专家对于软件系统的思维模型。通用语言和那些战略和战术性的建模模式同等重要，在有些情况下甚至更具有持久性。
简单地讲， DDD-Lite将导致劣质的领域对象，因为通用语言、限界上下文和上下文映射图的作用太大了，你从其中获得的并不只是一套团队共用的语言。在限界上下文中用通用语言来表述一个领域模型可以增加业务价值，并且使我们确信所开发软件的正确性。即使从技术的角度，它也可以帮助我们创建更好的领域模型，这样的模型行为丰满，业务纯净，并且可以减少犯错误的可能性。因此，我将战略设计模式映射到了可理解的实际例子中。
本书对于 DDD的映射可以帮助你同时体会到战略设计和战术设计的好处。通过一些具体的例子，你将感受到这些 DDD映射的业务价值和技术展现力。
如果我们对于 DDD的所有实践都只是停留在“地面上”，那将是令人失望的。过度地拘泥于细节将使我们丧失在空中俯瞰的机会。所以，不要将自己局限在地面的细节上，要勇敢地飞翔在空中，居高临下。搭上战略设计的航班，去了解限界上下文和上下文映射图，你将获得更广阔的视野。当你从 DDD的航班中获益时，我的目的也就达到了。