领域驱动设计精简版--阅读笔记

 

 

 

 

 

 

 

用简练的词汇描述DDD（Domain Driven Design） 的中心思想，我的回答是“关注精简的业务模型及实现的匹配”。

1、“模型”的定义是对现实的有选择性的精简

2、对象并不是独立存在的，它们之间有着千丝万缕的联系。这种扯不断理还乱的联系构成了系统的复杂性。

我们应该如何在一个更高点的层次上，通过保留对象之间有用的关系去除无用的关系，并且限定变更影响的范围以来降低系统的复杂度呢？

3. 在DDD 以及传统OO 的观点中，业务而不是技术是一个开发团队首先要关注的内容

4、不同的模型，需要不同的团队模型的支撑，不同的团队模型也会让一个模实现更优秀或者更糟糕。

5. 相信很多人读过ATM 机的例子，你发现自己彻底明白了用例应该怎么编写、模型怎么提取和实现，

但是当你信心十足地去开始你自己的项目时，你又会发现所有你明白了的技能在你的新项目中好像用不上。

算了，还是老的工作思路和工作方式比较顺手，于是一切都照旧会到了老的套路上。

那么，面向对象技术或者说我们提炼出来的模型应该如何在大型项目/团队中使用呢？我们是应该要求一个项目使

用统一的模型，还是应该把它们分成不同的模型？我们应该如何抉择？

简介........................................ 1
何为领域驱动设计.............................. 2
构建领域知识................................. 4
通用语言...................................... 8
对公共语言的需要............................. 8
创建通用语言................................. 9
模型驱动设计................................. 13
模型驱动设计的基本构成要素.................. 15
分层架构.................................... 16
实体........................................ 18
值对象...................................... 19
服务........................................ 21
模块........................................ 23
聚合........................................ 24
工厂........................................ 26
资源库...................................... 29
面向深层理解的重构........................... 34
持续重构.................................... 34
凸现关键概念................................ 35
保持模型的一致性............................. 39
界定的上下文................................ 40
持续集成.................................... 42
上下文映射.................................. 42
共享内核.................................... 43
客户-供应商................................. 44
顺从者...................................... 46
防崩溃层.................................... 47
隔离通道.................................... 48
开放主机服务................................ 49
提炼........................................ 49