领域驱动设计模式、原理与实践

出版者:清华大学出版社

作者:Scott Millett

页数:726

译者:蒲成

出版时间:2016-2-1

价格:CNY 99.80

装帧:平装

isbn号码:9787302428909

作者简介

Scott Millett是Iglu.com的IT总监，从1.0版本开始就使用.NET工作了。他在2010年和2011年获得了ASP.NET MVP，并且还著有《ASP.NET设计模式》和《精通.NET企业项目开发：最新的模式、工具与方法》。

Nick Tune是用技术、协作和领域驱动设计为复杂业务问题提供解决方案的软件开发者。通过开发目标宏伟的产品以及与充满热情的人一起工作，他在寻求不断地自我提升。

目录信息

第1部分领域驱动设计的原则与实践
第1章什么是领域驱动设计
1.1为复杂问题域创建软件的挑战
1.1.1未使用通用语言创建的代码
1.1.2组织结构的缺乏
1.1.3泥球模式将扼杀开发
1.1.4缺乏对问题域的关注
1.2领域驱动设计模式如何管理复杂性
1.2.1DDD的战略模式
1.2.2DDD的战术模式
1.2.3问题空间与解空间
1.3领域驱动设计的实践与原则
1.3.1专注于核心领域
1.3.2通过协作进行学习
1.3.3通过探索和实验来创建模型
1.3.4通信
1.3.5理解模型的适用性
1.3.6让模型持续发展
1.4领域驱动设计的常见误区
1.4.1战术模式是DDD的关键
1.4.2DDD是一套框架
1.4.3DDD是一颗灵丹妙药
1.5要点
第2章提炼问题域
2.1知识提炼与协作
2.1.1通过通用语言达成共识
2.1.2领域知识的重要性
2.1.3业务分析员的角色
2.1.4一个持续过程
2.2与领域专家一起获得领域见解
2.2.1领域专家与业务相关人员的对比
2.2.2对于业务的更深刻理解
2.2.3与你的领域专家互动
2.3有效提炼知识的模式
2.3.1专注在最有意思的对话上
2.3.2从用例开始
2.3.3提出有力的问题
2.3.4草图
2.3.5CRC卡
2.3.6延迟对模型中概念的命名
2.3.7行为驱动开发
2.3.8快速成型
2.3.9查看基于纸面的系统
2.4查看现有模型
2.4.1理解意图
2.4.2事件风暴
2.4.3影响地图
2.4.4理解业务模型
2.4.5刻意发现
2.4.6模型探讨漩涡
2.5要点
第3章专注于核心领域
3.1为何要分解一个问题域
3.2如何捕获问题的实质
3.2.1超越需求
3.2.2为达成什么是核心内容的共识而捕获领域愿景
3.3如何专注于核心问题
3.3.1提炼问题域
3.3.2核心领域
3.3.3将你的核心领域当作一款产品而非一个项目
3.3.4通用域
3.3.5支撑域
3.4子域如何决定解决方案的形成
3.5并非一个系统的所有部分都会经过良好设计
3.5.1专注于清晰边界而非完美模型
3.5.2一开始核心领域不必总是需要是完美的
3.5.3构建用于替代而非重用的子域
3.6如果没有核心领域怎么办
3.7要点
第4章模型驱动设计
4.1什么是领域模型
4.1.1领域与领域模型的对比
4.1.2分析模型
4.1.3代码模型
4.1.4代码模型是领域模型的主要表现
4.2模型驱动设计
4.2.1预先设计的挑战
4.2.2团队建模
4.3使用通用语言将分析和代码模型绑定在一起
4.3.1语言的生存周期将大于软件
4.3.2业务语言
4.3.3开发人员和业务之间的转译
4.4基于通用语言进行协作
4.4.1通过使用具体示例来定制出语言
4.4.2教导你的领域专家专注在问题上而不要跳到解决方案
4.4.3塑造语言的最佳实践
4.5如何创建有效的领域模型
4.5.1不要让实情妨碍一个好模型
4.5.2仅对相关内容建模
4.5.3领域模型都是暂时有用的
4.5.4要十分清楚专业术语
4.5.5限制你的抽象
4.6何时应用模型驱动设计
4.6.1如果它不值得花费精力，则不要尝试对其建模
4.6.2专注于核心领域
4.7要点
第5章领域模型实现模式
5.1领域层
5.2领域模型实现模式
5.2.1领域模型
5.2.2事务脚本
5.2.3表模块
5.2.4活动记录
5.2.5贫血领域模型
5.2.6贫血领域模型和函数编程
5.3要点
第6章使用有界上下文维护领域模型的完整性
6.1单个模型的挑战
6.1.1模型的复杂性可能会增加
6.1.2多个团队处理单个模型
6.1.3模型语言中的歧义
6.1.4领域概念的适用范围
6.1.5集成遗留代码或第三方代码
6.1.6领域模型并非企业模型
6.2使用有界上下文划分和破除大模型
6.2.1定义模型的边界
6.2.2子域和有界上下文之间的差异
6.3实现有界上下文
6.4要点
第7章上下文映射
7.1一个现实情况的映射
7.1.1技术的现实
7.1.2组织的现实
7.1.3映射一个相关现实情况
7.1.4用X标记核心领域的位置
7.2认识有界上下文之间的关系
7.2.1防止损坏层
7.2.2共享内核
7.2.3开放宿主服务
7.2.4分道扬镳
7.2.5合作关系
7.2.6一种上游／下游关系
7.3传递上下文映射
7.4上下文映射的战略重要性
7.4.1保持完整性
7.4.2解决计划的基础
7.4.3理解所有权和职责
7.4.4揭示业务工作流中的混乱区域
7.4.5识别非技术障碍
7.4.6鼓励良好的沟通
7.4.7帮助加入的新员工
7.5要点
第8章应用程序架构
8.1应用程序架构
8.1.1分离应用程序的问题
8.1.2从领域的复杂性中进行抽象
8.1.3分层架构
8.1.4依赖倒置
8.1.5领域层
8.1.6应用程序服务层
8.1.7基础架构层
8.1.8跨层通信
8.1.9隔离测试
8.1.10不要在有界上下文之间共享数据结构
8.1.11应用程序架构与用于有界上下文的架构的对比
8.2应用程序服务
8.2.1应用程序逻辑与领域逻辑的对比
8.2.2定义和公开能力
8.2.3业务用例协作
8.2.4应用程序服务表示的是用例，而不是创建、读取、更新和删除
8.2.5作为实现详情的领域层
8.2.6领域报告
8.2.7读取模型与事务模型的对比
8.3应用程序客户端
8.4要点
第9章团队开始应用领域驱动设计通常会遭到的问题
9.1过分强调战术模式的重要性
9.1.1将相同架构用于所有的有界上下文
9.1.2力求战术模式尽善尽美
9.1.3错误估计构造块对于DDD的价值
9.1.4专注于代码而非DDD的原则
9.2缺失了DDD的真实价值：协作、通信和上下文
9.2.1由于低估上下文的重要性而产生大泥球
9.2.2未能成功创建UL将造成歧义和误解
9.2.3由于缺乏协作将只能设计专注于技术的解决方案
9.3在不重要的部分花费太多时间
9.4简单问题复杂化
9.4.1将DDD原则应用到具有少量业务预期的琐碎领域
9.4.2别将CRUD作为反模式
9.4.3将领域模型模式用于每一个有界上下文
9.4.4问一问自己：额外的复杂性是否值得
9.5低估应用DDD的成本
9.5.1尝试在没有积极专注的团队的情况下取得成功
9.5.2项目背后没有领域专家时的协作尝试
9.5.3在非迭代式开发方法中进行学习
9.5.4将DDD应用到每一个问题
9.5.5为不必要的纯粹性而牺牲实用主义
9.5.6寻求验证会浪费精力
9.5.7永远力求代码之美
9.5.8DDD关乎的是提供价值
9.6要点
第10章应用DDD的原则、实践与模式
10.1推广使用DDD
10.1.1培训团队
10.1.2与业务人员进行交流
10.2应用DDD的原则
10.2.1理解愿景
10.2.2捕获所需的行为
10.2.3理解环境的现实情况
10.2.4对解决方案建模
10.3探究和实验
10.3.1质疑假设
10.3.2建模是一项持续性活动
10.3.3不存在错误的模型
10.3.4灵活的代码有助于探索发现
10.4让隐式内容变得显式
10.4.1处理歧义
10.4.2为事物命名
10.5问题解决人先行，技术专家后行
10.6如何才能知道我在正确地工作
10.6.1好用就足够了
10.6.2实践、实践、实践
10.7要点
第Ⅱ部分战略模式：在有界上下文之间通信
第11章有界上下文集成介绍
11.1如何集成有界上下文
11.1.1有界上下文是独立自主的
11.1.2在代码层面集成有界上下文的挑战
11.1.3使用物理边界来强制实现整洁的模型
11.1.4集成遗留系统
11.2集成分布式有界上下文
11.2.1集成用于分布式有界上下文的策略
11.2.2数据库集成
11.2.3平面文件集成
11.2.4RPC
11.2.5消息传递
11.2.6REST
11.3DDD使用分布式系统的挑战
11.4分布式事务将损害可扩展性和可靠性
11.4.1有界上下文不必彼此保持一致
11.4.2最终一致性
11.5事件驱动响应式DDD
11.5.1展示响应式解决方案的弹性和可扩展性
11.5.2异步消息传递的挑战和取舍
11.5.3RPC还有价值吗
11.6SOA和响应式DDD
11.6.1将你的有界上下文视作SOA服务
11.6.2进一步处理微服务架构
11.7要点
第12章通过消息传递集成
12.1消息传递基础
12.1.1消息总线
12.1.2可靠的消息传递
12.1.3存储转发
12.1.4命令和事件
12.1.5最终一致性
12.2使用NServiceBus构建一个电子商务应用程序
12.2.1系统设计
12.2.2从Web应用程序发送命令
12.2.3处理命令和发布事件
12.2.4使用消息传递网关让外部HTTP调用变得可靠
12.2.5实践中的最终一致性
12.2.6有界上下文会存储其本地所需的所有数据
12.2.7把所有内容都放在UI中
12.3维护消息传递应用程序
12.3.1消息版本管理
12.3.2监控和扩展
12.4将有界上下文与公共传输集成
12.4.1消息传递桥
12.4.2公共传输
12.5要点
第13章通过使用RPC和REST的HTTP来集成
13.1为何选用HTTP
13.1.1没有平台耦合
13.1.2每个人都理解HTTP
13.1.3大量的成熟工具和库
13.1.4内部测试你的API
13.2RPC
13.2.1在HTTP上实现RPC
13.2.2选择一种RPC风格
13.3REST
13.3.1深入浅出地解释REST
13.3.2用于有界上下文集成的REST
13.3.3维护REST应用程序
13.3.4将REST用于有界上下文集成的缺点
13.4要点
……
第Ⅲ部分战术模式：创建有效的领域模型
第Ⅳ部分有效应用程序的设计模式
· · · · · · (收起)

用户评价

最近几年，我深切体会到，软件的复杂度往往不是技术本身带来的，而是源于对业务领域理解的偏差和业务需求的频繁变动。因此，我非常关注如何让技术更好地服务于业务。我希望这本书能提供一种“双向的桥梁”，既能让技术人员理解业务语言，也能让领域专家理解技术约束。如果书中能够详细阐述如何从模糊的业务需求中提炼出清晰的“限界上下文”（Bounded Context）和核心的“实体”（Entity），那对我来说价值无量。我尤其关注书中对“领域事件”和“聚合根”这些核心概念的处理方式，它们是构建一致性和响应式系统的基石。我期待它能用一种非常系统化的方式，将这些看似零散的概念串联起来，形成一个完整的、可操作的蓝图，指导我们如何将那些错综复杂的业务逻辑，优雅地映射到软件模型中去。

从书名来看，它似乎涵盖了从理论基础到实际应用的完整周期，这正是我在寻找的。我担心有些书籍要么太偏向理论研究，读起来像哲学论文，要么就是只关注某一个特定框架的集成，缺乏普适性。我希望这本书能够保持一种恰到好处的平衡——既有坚实的理论根基作为支撑，确保我们理解的是“道”，而不是仅仅学会了“术”；又能提供足够的实践指导，让我们知道在实际编码时，究竟该如何组织文件结构、如何进行版本迭代。特别是，我非常好奇作者如何处理“演进式架构”的问题，因为在真实世界中，领域模型很少是一蹴而就的，它需要不断迭代和重构。如果书中能提供一套关于如何安全地、渐进地重构现有系统的策略，那这本书的实用价值将大大提升。

坦白说，我买这本书是冲着“模式”这两个字去的，因为在我看来，任何领域的核心都在于那些经过时间检验、被广泛认可的解决方案模板。我希望这本书不仅仅是罗列一堆设计模式的名字，而是能深入剖析每种模式背后的“为什么”——它解决了什么特定的领域挑战？它的适用范围和局限性在哪里？如果能用生动的比喻或者类比来解释那些晦涩的模式，那就更好了，这样即便是领域知识相对薄弱的开发者也能快速理解。我非常看重那种能够提升思维层次的阐述，而不是停留在代码实现的层面。真正的模式是关于如何思考和建模，而不是简单的复制粘贴。我期待这本书能帮助我建立一套更具前瞻性的架构思维，让我能够预见潜在的复杂性，并提前设计出具有高适应性的结构，避免未来陷入“屎山”的泥淖。

这部书的封面设计挺抓人眼球的，那种深邃的蓝色调和几何图形的组合，一下子就让人感觉这本书不简单，充满了技术深度。我其实是对软件架构设计一直很感兴趣，但总觉得很多现有的书籍要么过于理论化，要么就是只讲皮毛，不够深入。我特别期待这本书能提供一些实实在在、可以落地的方法论，不仅仅是介绍一些概念，更能展示如何在实际项目中运用这些模式来解决复杂性。我希望能看到它如何将抽象的业务领域知识转化为清晰、可维护的代码结构，这才是关键。书里如果能有大量真实的案例分析，那就更完美了，毕竟纸上谈兵远不如实战经验来得有说服力。我希望这本书能成为我手中那本“工具箱”里的核心装备，让我在面对大型、复杂的业务系统时，不再感到无从下手，而是能心中有数，游刃有余地构建出健壮的系统。

我个人对技术文档的排版和图示要求比较高，毕竟涉及到抽象概念的理解，清晰的视觉辅助至关重要。我期望这本书的插图和图表不仅仅是装饰，而是能够真正起到“解释器”的作用，比如用流程图清晰地展示一个命令的生命周期，或者用结构图展示不同服务间的依赖关系。如果作者能在书中穿插一些常见误区的“反面教材”，并详细解释为什么那样做是错误的以及正确的做法是什么，那对我的学习帮助会非常大。我希望这本书读完后，我不仅仅是“知道”了这些模式，而是能够“运用”它们，并且能够在代码评审中，自信地指出架构上的优缺点，并提出建设性的改进意见。它应该是一本能够显著提高我作为架构师或高级开发者的“话语权”和“决策质量”的参考书。

还是挺全面的一本书，提到了自己很多项目中遇到的问题，尤其在聚合与应用服务方面。但整体而言还是比较浅的，没讲得特别详细。但还是作为必读的参考书目

还是挺全面的一本书，提到了自己很多项目中遇到的问题，尤其在聚合与应用服务方面。但整体而言还是比较浅的，没讲得特别详细。但还是作为必读的参考书目

领域相关的技术也就是那么多，更重要的是应用的时候如何将业务边界和建模搞定？

看了前几章，翻译太差了。推荐《实现领域驱动设计》，vaughn vernon，比这本好些。

翻译太拗口