内容简介 · · · · · ·
《领域驱动设计:软件核心复杂性应对之道》是领域驱动设计方面的经典之作。全书围绕着设计和开发实践,结合若干真实的项目案例,向读者阐述如何在真实的软件开发中应用领域驱动设计。书中给出了领域驱动设计的系统化方法,并将人们普遍接受的一些最佳实践综合到一起,融入了作者的见解和经验,展现了一些可扩展的设计最佳实践、已验证过的技术以及便于应对复杂领域的软件项目开发的基本原则。《领域驱动设计:软件核心复杂性应对之道》适合各层次的面向对象软件开发人员、系统分析员阅读。
作者简介 · · · · · ·
Eric Evans “领域驱动设计之父”,世界杰出软件建模专家。他创建了Domain Language公司,致力于帮助公司机构创建与业务紧密相关的软件。他在世界各地宣讲领域驱动设计(Domain-Driven Design,DDD)的思想,开设课程,参加会议,接受专访,拥有大批的追随者。从20世纪80年代开始,他就以设计师和程序员的双重身份参与过许多大型面向对象系统的设计和开发,涉及各种复杂的业务和技术领域。同时,他还培训和指导过许多开发团队开展极限编程实践。
目录 · · · · · ·
第一部分 让领域模型发挥作用
第1章 消化知识
1.1 有效建模的要素
1.2 知识消化
1.3 持续学习
1.4 知识丰富的设计
1.5 深层模型
第2章 语言的交流和使用
2.1 模式:UBIQUITOUS LANGUAGE
2.2 “大声地”建模
2.3 一个团队,一种语言
2.4 文档和图
2.4.1 书面设计文档
2.4.2 完全依赖可执行代码的情况
2.5 解释性模型
第3章 绑定模型和实现
3.1 模式:MODEL-DRIVEN DESIGN
3.2 建模范式和工具支持
3.3 揭示主旨:为什么模型对用户至关重要
3.4 模式:HANDS-ON MODELER
第二部分 模型驱动设计的构造块
第4章 分离领域
4.1 模式:LAYERED ARCHITECTURE
4.1.1 将各层关联起来
4.1.2 架构框架
4.2 模型属于领域层
4.3 模式:THE SMART UI“ANTI-PATTERN”
4.4 其他分离方式
第5章 软件中所表示的模型
5.1 关联
5.2 模式:ENTITY(又称为REFERENCE OBJECT)
5.2.1 ENTITY建模
5.2.2 设计标识操作
5.3 模式:VALUE OBJECT
5.3.1 设计VALUE OBJECT
5.3.2 设计包含VALUE OBJECT的关联
5.4 模式:SERVICE
5.4.1 SERVICE与孤立的领域层
5.4.2 粒度
5.4.3 对SERVICE的访问
5.5 模式:MODULE(也称为PACKAGE)
5.5.1 敏捷的MODULE
5.5.2 基础设施驱动的打包存在的隐患
5.6 建模范式
5.6.1 对象范式流行的原因
5.6.2 对象世界中的非对象
5.6.3 在混合范式中坚持使用MODEL-DRIVEN DESIGN
第6章 领域对象的生命周期
6.1 模式:AGGREGATE
6.2 模式:FACTORY
6.2.1 选择FACTORY及其应用位置
6.2.2 有些情况下只需使用构造函数
6.2.3 接口的设计
6.2.4 固定规则的逻辑应放置在哪里
6.2.5 ENTITY FACTORY与VALUE OBJECT FACTORY
6.2.6 重建已存储的对象
6.3 模式:REPOSITORY
6.3.1 REPOSITORY的查询
6.3.2 客户代码可以忽略REPOSITORY的实现,但开发人员不能忽略
6.3.3 REPOSITORY的实现
6.3.4 在框架内工作
6.3.5 REPOSITORY与FACTORY的关系
6.4 为关系数据库设计对象
第7章 使用语言:一个扩展的示例
7.1 货物运输系统简介
7.2 隔离领域:应用程序的引入
7.3 将ENTITY和VALUE OBJECT区别开
7.4 设计运输系统中的关联
7.5 AGGREGATE边界
7.6 选择REPOSITORY
7.7 场景走查
7.7.1 应用程序特性举例:更改Cargo的目的地
7.7.2 应用程序特性举例:重复业务
7.8 对象的创建
7.8.1 Cargo的FACTORY和构造函数
7.8.2 添加一个Handling Event
7.9 停下来重构:Cargo AGGREGATE的另一种设计
7.10 运输模型中的MODULE
7.11 引入新特性:配额检查
7.11.1 连接两个系统
7.11.2 进一步完善模型:划分业务
7.11.3 性能优化
7.12 小结
第三部分 通过重构来加深理解
第8章 突破
8.1 一个突破的故事
8.1.1 华而不实的模型
8.1.2 突破
8.1.3 更深层模型
8.1.4 冷静决策
8.1.5 成果
8.2 机遇
8.3 关注根本
8.4 后记:越来越多的新理解
第9章 将隐式概念转变为显式概念
9.1 概念挖掘
9.1.1 倾听语言
9.1.2 检查不足之处
9.1.3 思考矛盾之处
9.1.4 查阅书籍
9.1.5 尝试,再尝试
9.2 如何为那些不太明显的概念建模
9.2.1 显式的约束
9.2.2 作为领域对象的过程
9.2.3 模式:SPECIFICATION
9.2.4 SPECIFICATION的应用和实现
第10章 柔 性 设 计
10.1 模式:INTENTION-REVEALING INTERFACES
10.2 模式:SIDE-EFFECT-FREE FUNCTION
10.3 模式:ASSERTION
10.4 模式:CONCEPTUAL CONTOUR
10.5 模式:STANDALONE CLASS
10.6 模式:CLOSURE OF OPERATION
10.7 声明式设计
10.8 声明式设计风格
10.9 切入问题的角度
10.9.1 分割子领域
10.9.2 尽可能利用已有的形式
第11章 分析模式的应用
第12章 将设计模式应用于模型
12.1 模式:STRATEGY(也称为POLICY)
12.2 模式:COMPOSITE
12.3 为什么没有介绍FLYWEIGHT
第13章 通过重构得到更深层的理解
13.1 开始重构
13.2 探索团队
13.3 借鉴先前的经验
13.4 针对开发人员的设计
13.5 重构的时机
13.6 危机就是机遇
第四部分 战略设计
第14章 保持模型的完整性
14.1 模式:BOUNDED CONTEXT
14.2 模式:CONTINUOUS INTEGRATION
14.3 模式:CONTEXT MAP
14.3.1 测试CONTEXT的边界
14.3.2 CONTEXT MAP的组织和文档化
14.4 BOUNDED CONTEXT之间的关系
14.5 模式:SHARED KERNEL
14.6 模式:CUSTOMER/SUPPLIERDEVELOPMENT TEAM
14.7 模式:CONFORMIST
14.8 模式:ANTICORRUPTION LAYER
14.8.1 设计ANTICORRUPTION LAYER的接口
14.8.2 实现ANTICORRUPTION LAYER
14.8.3 一个关于防御的故事
14.9 模式:SEPARATE WAY
14.10 模式:OPEN HOST SERVICE
14.11 模式:PUBLISHED LANGUAGE
14.12 “大象”的统一
14.13 选择你的模型上下文策略
14.13.1 制定团队决策或更高层的决策
14.13.2 在上下文中工作
14.13.3 转换边界
14.13.4 接受那些我们无法更改的事物:描述外部系统
14.13.5 与外部系统的关系
14.13.6 正在设计的系统
14.13.7 满足不同模型的特殊需要
14.13.8 部署
14.13.9 权衡
14.13.10 当项目正在进行时
14.14 转换
14.14.1 合并CONTEXT:SEPARATE WAY →SHARED KERNEL
14.14.2 合并CONTEXT:SHARED KERNEL→CONTINUOUS INTEGRATION
14.14.3 逐步淘汰遗留系统
14.14.4 OPEN HOST SERVICE→PUBLISHED LANGUAGE
第15章 精炼
15.1 模式:CORE DOMAIN
15.1.1 选择核心
15.1.2 工作的分配
15.2 精炼的逐步提升
15.3 模式:GENERIC SUBDOMAIN
15.3.1 通用不等于可以重用
15.3.2 项目风险管理
15.4 模式:DOMAIN VISION STATEMENT
15.5 模式:HIGHLIGHTED CORE
15.5.1 精炼文档
15.5.2 标明CORE
15.5.3 把精炼文档作为过程工具
15.6 模式:COHESIVE MECHANISM
15.6.1 GENERIC SUBDOMAIN与COHE-SIVE MECHANISM的比较
15.6.2 MECHANISM是CORE DOMAIN一部分
15.7 通过精炼得到声明式风格
15.8 模式:SEGREGATED CORE
15.8.1 创建SEGREGATED CORE的代价
15.8.2 不断发展演变的团队决策
15.9 模式:ABSTRACT CORE
15.10 深层模型精炼
15.11 选择重构目标
第16章 大比例结构
16.1 模式:EVOLVING ORDER
16.2 模式:SYSTEM METAPHOR
16.3 模式:RESPONSIBILITY LAYER
16.4 模式:KNOWLEDGE LEVEL
16.5 模式:PLUGGABLE COMPONENT FRAMEWORK
16.6 结构应该有一种什么样的约束
16.7 通过重构得到更适当的结构
16.7.1 最小化
16.7.2 沟通和自律
16.7.3 通过重构得到柔性设计
16.7.4 通过精炼可以减轻负担
第17章 领域驱动设计的综合运用
17.1 把大比例结构与BOUNDED CONTEXT结合起来使用
17.2 将大比例结构与精炼结合起来使用
17.3 首先评估
17.4 由谁制定策略
17.4.1 从应用程序开发自动得出的结构
17.4.2 以客户为中心的架构团队
17.5 制定战略设计决策的6个要点
17.5.1 技术框架同样如此
17.5.2 注意总体规划
结束语
附录
术语表
参考文献
图片说明
索引
· · · · · · (收起)
第1章 消化知识
1.1 有效建模的要素
1.2 知识消化
1.3 持续学习
1.4 知识丰富的设计
1.5 深层模型
第2章 语言的交流和使用
2.1 模式:UBIQUITOUS LANGUAGE
2.2 “大声地”建模
2.3 一个团队,一种语言
2.4 文档和图
2.4.1 书面设计文档
2.4.2 完全依赖可执行代码的情况
2.5 解释性模型
第3章 绑定模型和实现
3.1 模式:MODEL-DRIVEN DESIGN
3.2 建模范式和工具支持
3.3 揭示主旨:为什么模型对用户至关重要
3.4 模式:HANDS-ON MODELER
第二部分 模型驱动设计的构造块
第4章 分离领域
4.1 模式:LAYERED ARCHITECTURE
4.1.1 将各层关联起来
4.1.2 架构框架
4.2 模型属于领域层
4.3 模式:THE SMART UI“ANTI-PATTERN”
4.4 其他分离方式
第5章 软件中所表示的模型
5.1 关联
5.2 模式:ENTITY(又称为REFERENCE OBJECT)
5.2.1 ENTITY建模
5.2.2 设计标识操作
5.3 模式:VALUE OBJECT
5.3.1 设计VALUE OBJECT
5.3.2 设计包含VALUE OBJECT的关联
5.4 模式:SERVICE
5.4.1 SERVICE与孤立的领域层
5.4.2 粒度
5.4.3 对SERVICE的访问
5.5 模式:MODULE(也称为PACKAGE)
5.5.1 敏捷的MODULE
5.5.2 基础设施驱动的打包存在的隐患
5.6 建模范式
5.6.1 对象范式流行的原因
5.6.2 对象世界中的非对象
5.6.3 在混合范式中坚持使用MODEL-DRIVEN DESIGN
第6章 领域对象的生命周期
6.1 模式:AGGREGATE
6.2 模式:FACTORY
6.2.1 选择FACTORY及其应用位置
6.2.2 有些情况下只需使用构造函数
6.2.3 接口的设计
6.2.4 固定规则的逻辑应放置在哪里
6.2.5 ENTITY FACTORY与VALUE OBJECT FACTORY
6.2.6 重建已存储的对象
6.3 模式:REPOSITORY
6.3.1 REPOSITORY的查询
6.3.2 客户代码可以忽略REPOSITORY的实现,但开发人员不能忽略
6.3.3 REPOSITORY的实现
6.3.4 在框架内工作
6.3.5 REPOSITORY与FACTORY的关系
6.4 为关系数据库设计对象
第7章 使用语言:一个扩展的示例
7.1 货物运输系统简介
7.2 隔离领域:应用程序的引入
7.3 将ENTITY和VALUE OBJECT区别开
7.4 设计运输系统中的关联
7.5 AGGREGATE边界
7.6 选择REPOSITORY
7.7 场景走查
7.7.1 应用程序特性举例:更改Cargo的目的地
7.7.2 应用程序特性举例:重复业务
7.8 对象的创建
7.8.1 Cargo的FACTORY和构造函数
7.8.2 添加一个Handling Event
7.9 停下来重构:Cargo AGGREGATE的另一种设计
7.10 运输模型中的MODULE
7.11 引入新特性:配额检查
7.11.1 连接两个系统
7.11.2 进一步完善模型:划分业务
7.11.3 性能优化
7.12 小结
第三部分 通过重构来加深理解
第8章 突破
8.1 一个突破的故事
8.1.1 华而不实的模型
8.1.2 突破
8.1.3 更深层模型
8.1.4 冷静决策
8.1.5 成果
8.2 机遇
8.3 关注根本
8.4 后记:越来越多的新理解
第9章 将隐式概念转变为显式概念
9.1 概念挖掘
9.1.1 倾听语言
9.1.2 检查不足之处
9.1.3 思考矛盾之处
9.1.4 查阅书籍
9.1.5 尝试,再尝试
9.2 如何为那些不太明显的概念建模
9.2.1 显式的约束
9.2.2 作为领域对象的过程
9.2.3 模式:SPECIFICATION
9.2.4 SPECIFICATION的应用和实现
第10章 柔 性 设 计
10.1 模式:INTENTION-REVEALING INTERFACES
10.2 模式:SIDE-EFFECT-FREE FUNCTION
10.3 模式:ASSERTION
10.4 模式:CONCEPTUAL CONTOUR
10.5 模式:STANDALONE CLASS
10.6 模式:CLOSURE OF OPERATION
10.7 声明式设计
10.8 声明式设计风格
10.9 切入问题的角度
10.9.1 分割子领域
10.9.2 尽可能利用已有的形式
第11章 分析模式的应用
第12章 将设计模式应用于模型
12.1 模式:STRATEGY(也称为POLICY)
12.2 模式:COMPOSITE
12.3 为什么没有介绍FLYWEIGHT
第13章 通过重构得到更深层的理解
13.1 开始重构
13.2 探索团队
13.3 借鉴先前的经验
13.4 针对开发人员的设计
13.5 重构的时机
13.6 危机就是机遇
第四部分 战略设计
第14章 保持模型的完整性
14.1 模式:BOUNDED CONTEXT
14.2 模式:CONTINUOUS INTEGRATION
14.3 模式:CONTEXT MAP
14.3.1 测试CONTEXT的边界
14.3.2 CONTEXT MAP的组织和文档化
14.4 BOUNDED CONTEXT之间的关系
14.5 模式:SHARED KERNEL
14.6 模式:CUSTOMER/SUPPLIERDEVELOPMENT TEAM
14.7 模式:CONFORMIST
14.8 模式:ANTICORRUPTION LAYER
14.8.1 设计ANTICORRUPTION LAYER的接口
14.8.2 实现ANTICORRUPTION LAYER
14.8.3 一个关于防御的故事
14.9 模式:SEPARATE WAY
14.10 模式:OPEN HOST SERVICE
14.11 模式:PUBLISHED LANGUAGE
14.12 “大象”的统一
14.13 选择你的模型上下文策略
14.13.1 制定团队决策或更高层的决策
14.13.2 在上下文中工作
14.13.3 转换边界
14.13.4 接受那些我们无法更改的事物:描述外部系统
14.13.5 与外部系统的关系
14.13.6 正在设计的系统
14.13.7 满足不同模型的特殊需要
14.13.8 部署
14.13.9 权衡
14.13.10 当项目正在进行时
14.14 转换
14.14.1 合并CONTEXT:SEPARATE WAY →SHARED KERNEL
14.14.2 合并CONTEXT:SHARED KERNEL→CONTINUOUS INTEGRATION
14.14.3 逐步淘汰遗留系统
14.14.4 OPEN HOST SERVICE→PUBLISHED LANGUAGE
第15章 精炼
15.1 模式:CORE DOMAIN
15.1.1 选择核心
15.1.2 工作的分配
15.2 精炼的逐步提升
15.3 模式:GENERIC SUBDOMAIN
15.3.1 通用不等于可以重用
15.3.2 项目风险管理
15.4 模式:DOMAIN VISION STATEMENT
15.5 模式:HIGHLIGHTED CORE
15.5.1 精炼文档
15.5.2 标明CORE
15.5.3 把精炼文档作为过程工具
15.6 模式:COHESIVE MECHANISM
15.6.1 GENERIC SUBDOMAIN与COHE-SIVE MECHANISM的比较
15.6.2 MECHANISM是CORE DOMAIN一部分
15.7 通过精炼得到声明式风格
15.8 模式:SEGREGATED CORE
15.8.1 创建SEGREGATED CORE的代价
15.8.2 不断发展演变的团队决策
15.9 模式:ABSTRACT CORE
15.10 深层模型精炼
15.11 选择重构目标
第16章 大比例结构
16.1 模式:EVOLVING ORDER
16.2 模式:SYSTEM METAPHOR
16.3 模式:RESPONSIBILITY LAYER
16.4 模式:KNOWLEDGE LEVEL
16.5 模式:PLUGGABLE COMPONENT FRAMEWORK
16.6 结构应该有一种什么样的约束
16.7 通过重构得到更适当的结构
16.7.1 最小化
16.7.2 沟通和自律
16.7.3 通过重构得到柔性设计
16.7.4 通过精炼可以减轻负担
第17章 领域驱动设计的综合运用
17.1 把大比例结构与BOUNDED CONTEXT结合起来使用
17.2 将大比例结构与精炼结合起来使用
17.3 首先评估
17.4 由谁制定策略
17.4.1 从应用程序开发自动得出的结构
17.4.2 以客户为中心的架构团队
17.5 制定战略设计决策的6个要点
17.5.1 技术框架同样如此
17.5.2 注意总体规划
结束语
附录
术语表
参考文献
图片说明
索引
· · · · · · (收起)
丛书信息
· · · · · ·
图灵程序设计丛书·程序员修炼系列(共72册),
这套丛书还有
《代码之外的功夫》《高效程序员的45个习惯》《高效程序员的45个习惯(修订版)》《重构》《卓有成效的程序员》
等
。
喜欢读"领域驱动设计"的人也喜欢的电子书 · · · · · ·
支持 Web、iPhone、iPad、Android 阅读器
喜欢读"领域驱动设计"的人也喜欢 · · · · · ·
领域驱动设计的书评 · · · · · · ( 全部 27 条 )
看懂这本书你要先从真正理解名字开始!
看了对于此书的短评,把这本书看成是一本“正确的废话”的人我想不在少数,10年前我看此书也是一样的感觉,10年后微服务大火,很多人又把“领域驱动设计”挂在嘴边,此时我再看此书确实感觉自己看懂了,我想这其中的奥秘其实就在“领域驱动设计”这六个字里。让我给大家仔细分...
(展开)
方法论岂是那么好懂的
这篇书评可能有关键情节透露
如果没有两年的编程经验,如果对设计一个新项目的逻辑分层、包结构没有疑问,那么就别看这书了...看不懂的。 本书讲的是一种应对复杂软件系统设计的思想,作者若没个十几年的编程功底,沉淀不了这种方法论,写不出这种书。 光看一遍是看不懂的,摘录一些点慢慢消化吧。 大多数... (展开)> 更多书评 27篇
论坛 · · · · · ·
在这本书的论坛里发言这本书的其他版本 · · · · · · ( 全部7 )
-
人民邮电出版社 (2016)7.9分 428人读过
-
清华大学出版社 (2006)8.4分 308人读过
-
Addison-Wesley Professional (2003)8.3分 96人读过
-
人民邮电出版社 (2007)8.7分 19人读过
以下书单推荐 · · · · · · ( 全部 )
- 道可道,非常道 (透明)
- Web程序员的修炼之道 (火丁笔记)
- thoughtworks ([已软注销])
- 我的人生普及书籍 (jangwoohyuk)
- 2014年上书单 (6up7)
谁读这本书? · · · · · ·
二手市场
· · · · · ·
订阅关于领域驱动设计的评论:
feed: rss 2.0
0 有用 嘉陵 2011-02-20 21:24:59
很多概念无法深入理解,期待某天能顿悟作者的思想。
0 有用 且听风殇 2022-07-31 16:24:47
虽然是很久前的书了,但其中很多思想现在依旧适用
25 有用 颜小婧 2017-10-11 09:28:50
我觉得每句话我都要读两遍才能明白什么意思,是翻译的问题还是我智商的问题……
0 有用 敬爱的Ezio大叔 2023-04-15 04:29:46 上海
知易行难
2 有用 离开以后 2012-08-24 18:57:19
这书要常读
0 有用 KKK已不再 2024-03-08 09:38:02 广东
暂读了第一遍没太看明白吧。
0 有用 Seayon/阿阳 2024-01-19 08:56:17 上海
好像懂了点什么,好像什么也没懂
0 有用 Knight 2023-12-14 19:36:45 广东
有些内容感觉可以跳着看,有些太营销
0 有用 xiaocong 2023-08-19 22:37:28 浙江
常看常新
0 有用 敬爱的Ezio大叔 2023-04-15 04:29:46 上海
知易行难