下载链接: https://pan.baidu.com/s/1blrNz8is9bITa6d7EOD7lA 密码: psdv
- 出版社: 人民邮电出版社; 第2版 (2016年6月1日)
- 外文书名: Domain-Driven Design:Tackling Complexcity in the Heart of Software
- 平装: 370页
- 语种： 简体中文
- 开本: 16
- ISBN: 7115376751, 9787115376756
- 条形码: 9787115376756
- 商品尺寸: 23.4 x 18.6 x 1.8 cm
- 商品重量: 640 g
- 品牌: 人民邮电出版社
- ASIN: B01GZ6T12K
编辑推荐
● “领域驱动设计之父”经典著作
● 众多声名显赫软件大师鼎力推荐
● 凝聚领域建模专家数十年的实战经验
● 深度剖析构建高质量复杂系统的核心技术
领域模型使开发人员可以表达丰富的软件功能需求，由此实现的软件可以满足用户真正的需要，因此被公认为是软件设计的关键所在，其重要性显而易见。但讲述如何将领域模型用于软件开发过程的杰出的实用资料却不多见。本书正是这一领域声名显赫的作品，受到众多业界大师的赞美和推介，广受读者好评。
要通过创建领域模型来加速复杂的软件开发，就需要利用大量实践和标准模式在开发团队中形成统一的交流语言；不但要重构代码，而且要重构代码底层的模型；同时采取反复迭代的敏捷开发方法，深入理解领域特点，促进领域专家与程序员的良好沟通。针对这些内容，本书结合真实项目，系统地介绍了领域驱动开发的目标、意义和方法，充分讨论了复杂系统的建模与设计问题。
本书将指导面向对象开发人员、系统分析人员和设计人员合理地组织工作，各有侧重、彼此协作，有条不紊地进行复杂系统的开发，帮助他们建立丰富而实用的领域模型，并由此创建长期适用的优质软件。
名人推荐
“这本书应该出现在每位软件开发人员的书架上。”
——Kent Beck，软件开发方法学泰斗，极限编程的创始人
“Eric的这本书太棒、太神奇了，他准确地告诉你如何让软件设计满足你的模型需求……本书读起来趣味无穷。Eric有许多有趣的故事，而且描述起来很有一套……它将成为软件开发人员必读的经典之作。”
——Ralph Johnson，《设计模式》的作者
“如果你认为自己在面向对象编程中的投入没有收到回报，读了这本书你就会知道自己漏掉了什么。”
——Ward Cunningham，设计模式和敏捷软件方法的先驱
“Eric Evans力证作为开发核心的领域模型的重要性。他搭建了一个稳固的框架，并提供了一套实现技术和技巧。这里沉淀下来的是亘古不变的智慧，在流行的方法论都沦为明日黄花后，它依然光华璀璨。”
——Dave Collins，Designing Object—Oriented User Interfaces的作者
“Eric完全从实战者的角度着笔，描述了通用的语言、与用户共享模型的好处、对象生命周期的管理、深度重构的过程和结果，这是对我们这个领域的巨大贡献。”
——Luke Hohmann，Beyond Software Architecture的作者
媒体推荐
“这本书应该出现在每位软件开发人员的书架上。”
——Kent Beck，软件开发方法学泰斗，极限编程的创始人
“Eric的这本书太棒、太神奇了，他准确地告诉你如何让软件设计满足你的模型需求……本书读起来趣味无穷。Eric有许多有趣的故事，而且描述起来很有一套……它将成为软件开发人员必读的经典之作。”
——Ralph Johnson，《设计模式》的作者
“如果你认为自己在面向对象编程中的投入没有收到回报，读了这本书你就会知道自己漏掉了什么。”
——Ward Cunningham，设计模式和敏捷软件方法的先驱
“Eric Evans力证作为开发核心的领域模型的重要性。他搭建了一个稳固的框架，并提供了一套实现技术和技巧。这里沉淀下来的是亘古不变的智慧，在流行的方法论都沦为明日黄花后，它依然光华璀璨。”
——Dave Collins，Designing Object-Oriented User Interfaces的作者
“Eric完全从实战者的角度着笔，描述了通用的语言、与用户共享模型的好处、对象生命周期的管理、深度重构的过程和结果，这是对我们这个领域的巨大贡献。”
——Luke Hohmann，Beyond Software Architecture的作者
作者简介
Eric Evans “领域驱动设计之父”，世界杰出软件建模专家。他创建了Domain Language公司，致力于帮助公司机构创建与业务紧密相关的软件。他在世界各地宣讲领域驱动设计（Domain-Driven Design，DDD）的思想，开设课程，参加会议，接受专访，拥有大批的追随者。从20世纪80年代开始，他就以设计师和程序员的双重身份参与过许多大型面向对象系统的设计和开发，涉及各种复杂的业务和技术领域。同时，他还培训和指导过许多开发团队开展极限编程实践。
目录
第一部分运用领域模型
第1章消化知识5
1.1有效建模的要素9
1.2知识消化10
1.3持续学习11
1.4知识丰富的设计12
1.5深层模型15
第2章交流与语言的使用16
2.1模式：UBIQUITOUS LANGUAGE16
2.2“大声地”建模21
2.3一个团队，一种语言22
2.4文档和图24
2.4.1书面设计文档25
2.4.2完全依赖可执行代码的情况27
2.5解释性模型27
第3章绑定模型和实现29
3.1模式：MODEL—DRIVEN DESIGN30
3.2建模范式和工具支持32
3.3揭示主旨：为什么模型对用户至关重要38
3.4模式：HANDS—ON MODELER39
第二部分模型驱动设计的构造块
第4章分离领域43
4.1模式：LAYERED ARCHITECTURE43
4.1.1将各层关联起来46
4.1.2架构框架47
4.2领域层是模型的精髓48
4.3模式：THE SMART UI“反模式”48
4.4其他分离方式50
第5章软件中所表示的模型51
5.1关联52
5.2模式：ENTITY（又称为REFERENCE OBJECT）56
5.2.1ENTITY建模59
5.2.2设计标识操作60
5.3模式：VALUE OBJECT62
5.3.1设计VALUE OBJECT64
5.3.2设计包含VALUE OBJECT的关联67
5.4模式：SERVICE67
5.4.1SERVICE与孤立的领域层69
5.4.2粒度70
5.4.3对SERVICE的访问70
5.5模式：MODULE（也称为PACKAGE）71
5.5.1敏捷的MODULE72
5.5.2通过基础设施打包时存在的隐患73
5.6建模范式75
5.6.1对象范式流行的原因76
5.6.2对象世界中的非对象77
5.6.3在混合范式中坚持使用MODEL—DRIVEN DESIGN78
第6章领域对象的生命周期80
6.1模式：AGGREGATE81
6.2模式：FACTORY89
6.2.1选择FACTORY及其应用位置91
6.2.2有些情况下只需使用构造函数93
6.2.3接口的设计94
6.2.4固定规则的相关逻辑应放置在哪里94
6.2.5ENTITY FACTORY与VALUEOBJECT FACTORY95
6.2.6重建已存储的对象95
6.3模式：REPOSITORY97
6.3.1REPOSITORY的查询101
6.3.2客户代码可以忽略REPOSITORY的实现，但开发人员不能忽略102
6.3.3REPOSITORY的实现103
6.3.4在框架内工作104
6.3.5REPOSITORY与FACTORY的关系104
6.4为关系数据库设计对象106
第7章使用语言：一个扩展的示例108
7.1货物运输系统简介108
7.2隔离领域：引入应用层110
7.3将ENTITY和VALUE OBJECT区别开110
7.4设计运输领域中的关联112
7.5AGGREGATE边界113
7.6选择REPOSITORY113
7.7场景走查115
7.7.1应用程序特性举例：更改Cargo的目的地115
7.7.2应用程序特性举例：重复业务116
7.8对象的创建116
7.8.1Cargo的FACTORY和构造函数116
7.8.2添加Handling Event117
7.9停一下，重构：Cargo AGGREGATE的另一种设计118
7.10运输模型中的MODULE120
7.11引入新特性：配额检查122
7.11.1连接两个系统123
7.11.2进一步完善模型：划分业务124
7.11.3性能优化125
7.12小结126
第三部分通过重构来加深理解
第8章突破131
8.1一个关于突破的故事131
8.1.1华而不实的模型132
8.1.2突破133
8.1.3更深层模型135
8.1.4冷静决策137
8.1.5成果138
8.2机遇138
8.3关注根本138
8.4后记：越来越多的新理解139
第9章将隐式概念转变为显式概念140
9.1概念挖掘140
9.1.1倾听语言140
9.1.2检查不足之处144
9.1.3思考矛盾之处148
9.1.4查阅书籍148
9.1.5尝试，再尝试150
9.2如何为那些不太明显的概念建模150
9.2.1显式的约束151
9.2.2将过程建模为领域对象153
9.2.3模式：SPECIFICATION154
9.2.4SPECIFICATION的应用和实现156
第10章柔性设计168
10.1模式：INTENTION—REVEALING INTERFACES169
10.2模式：SIDE—EFFECT—FREE FUNCTION173
10.3模式：ASSERTION177
10.4模式：CONCEPTUAL CONTOUR181
10.5模式：STANDALONE CLASS184
10.6模式：CLOSURE OF OPERATION186
10.7声明式设计188
10.8声明式设计风格190
10.9切入问题的角度197
10.9.1分割子领域197
10.9.2尽可能利用已有的形式198
第11章应用分析模式206
第12章将设计模式应用于模型217
12.1模式：STRATEGY（也称为POLICY）218
12.2模式：COMPOSITE221
12.3为什么没有介绍FLYWEIGHT226
第13章通过重构得到更深层的理解227
13.1开始重构227
13.2探索团队227
13.3借鉴先前的经验228
13.4针对开发人员的设计229
13.5重构的时机229
13.6危机就是机遇230
第四部分战略设计
第14章保持模型的完整性233
14.1模式：BOUNDED CONTEXT235
14.2模式：CONTINUOUS INTEGRATION239
14.3模式：CONTEXT MAP241
14.3.1测试CONTEXT的边界247
14.3.2CONTEXT MAP的组织和文档化247
14.4BOUNDED CONTEXT之间的关系248
14.5模式：SHARED KERNEL248
14.6模式：CUSTOMER／SUPPLIER DEVELOPMENT TEAM250
14.7模式：CONFORMIST253
14.8模式：ANTICORRUPTION LAYER255
14.8.1设计ANTICORRUPTION LAYER的接口256
14.8.2实现ANTICORRUPTION LAYER256
14.8.3一个关于防御的故事259
14.9模式：SEPARATE WAY260
14.10模式：OPENHOST SERVICE261
14.11模式：PUBLISHED LANGUAGE262
14.12“大象”的统一264
14.13选择你的模型上下文策略267
14.13.1团队决策或更高层决策268
14.13.2置身上下文中268
14.13.3转换边界268
14.13.4接受那些我们无法更改的事物：描述外部系统269
14.13.5与外部系统的关系269
14.13.6设计中的系统270
14.13.7用不同模型满足特殊需要270
14.13.8部署271
14.13.9权衡271
14.13.10当项目正在进行时272
14.14转换272
14.14.1合并CONTEXT：SEPARATE WAY→SHARED KERNEL273
14.14.2合并CONTEXT：SHARED KERNEL→CONTINUOUS INTEGRATION274
14.14.3逐步淘汰遗留系统275
14.14.4OPEN HOST SERVICE→PUBLISHED LANGUAGE276
第15章精炼277
15.1模式：CORE DOMAIN278
15.1.1选择核心280
15.1.2工作的分配280
15.2精炼的逐步提升281
15.3模式：GENERIC SUBDOMAIN282
15.3.1通用不等于可重用286
15.3.2项目风险管理287
15.4模式：DOMAIN VISION STATEMENT287
15.5模式：HIGHLIGHTED CORE289
15.5.1精炼文档289
15.5.2标明CORE290
15.5.3把精炼文档作为过程工具291
15.6模式：COHESIVE MECHANISM292
15.6.1GENERIC SUBDOMAIN与COHESIVE MECHANISM的比较293
15.6.2MECHANISM是COREDOMAIN一部分294
15.7通过精炼得到声明式风格294
15.8模式：SEGREGATED CORE295
15.8.1创建SEGREGATED CORE的代价296
15.8.2不断发展演变的团队决策296
15.9模式：ABSTRACT CORE301
15.10深层模型精炼302
15.11选择重构目标302
第16章大型结构303
16.1模式：EVOLVING ORDER306
16.2模式：SYSTEM METAPHOR308
16.3模式：RESPONSIBI LITYLAYER309
16.4模式：KNOWLEDGE LEVEL321
16.5模式：PLUGGABLE COMPONENT FRAMEWORK328
16.6结构应该有一种什么样的约束332
16.7通过重构得到更适当的结构333
16.7.1最小化333
16.7.2沟通和自律334
16.7.3通过重构得到柔性设计334
16.7.4通过精炼可以减轻负担334
第17章领域驱动设计的综合运用336
17.1把大型结构与BOUNDED CONTEXT结合起来使用336
17.2将大型结构与精炼结合起来使用339
17.3首先评估339
17.4由谁制定策略341
17.4.1从应用程序开发自动得出的结构341
17.4.2以客户为中心的架构团队341
17.5制定战略设计决策的6个要点342
17.5.1技术框架同样如此344
17.5.2注意总体规划345
结束语
附录351
术语表354
参考文献357
图片说明359
索引360
文摘
版权页： 
对象建模有可能把我们的注意力引到对象的属性上，但实体的基本概念是一种贯穿整个生命周期（甚至会经历多种形式）的抽象的连续性。
一些对象主要不是由它们的属性定义的。它们实际上表示了一条“标识线”（A Thread of Identity），这条线跨越时间，而且常常经历多种不同的表示。有时，这样的对象必须与另一个具有不同属性的对象相匹配。而有时一个对象必须与具有相同属性的另一个对象区分开。错误的标识可能会破坏数据。
主要由标识定义的对象被称作ENTITY。ENTITY（实体）有特殊的建模和设计思路。它们具有生命周期，这期间它们的形式和内容可能发生根本改变，但必须保持一种内在的连续性。为了有效地跟踪这些对象，必须定义它们的标识。它们的类定义、职责、属性和关联必须由其标识来决定，而不依赖于其所具有的属性。即使对于那些不发生根本变化或者生命周期不太复杂的ENTITY，也应该在语义上把它们作为ENTITY来对待，这样可以得到更清晰的模型和更健壮的实现。
当然，软件系统中的大多数“ENTITY”并不是人，也不是其通常意义上所指的“实体”或“存在”。ENTITY可以是任何事物，只要满足两个条件即可，一是它在整个生命周期中具有连续性，二是它的区别并不是由那些对用户非常重要的属性决定的。ENTITY可以是一个人、一座城市、一辆汽车、一张彩票或一次银行交易。