《领域驱动设计》读书笔记
前言和目录⌗
好的软件需要控制复杂性，好的领域模型可以帮助控制复杂性。
什么样的项目需要 DDD？尝试型的小型项目应该不需要 DDD，但是一旦上了规模考虑后续迭代则需要 DDD。
本书组织方式：
领域建模⌗
领域建模的过程就是消化知识的过程，这个过程应该贯穿整个开发过程，需要持续学习。
-
模型用来描绘人们所关注的实现或想法的某个方面，比如地图就是模型。
-
模型是一种简化，是对实现的解释：把与解决问题密切相关的方面抽象出来，而忽略无关的细节。
软件问题建模的区域就是软件的领域
- 物质世界的领域：机票预订程序涉及的飞机乘客。
- 无形的领域：会计程序的金融领域。
领域涉及知识信息超载的问题，模型这种知识对知识进行了选择性的简化和有意的结构化。
-
领域模型将领域专家头脑中的支持严格的组织且有选择的抽象，并不是尽可能建立一个符合“现实”的模型。
模型表示⌗
关联⌗
- 规定一个遍历方向：存在双向联结时（地址 -> 人 或 人 -> 地址）尽量只用一种，并避免互相关联
- 添加一个限定符，以便有效减少多重关联
- 消除不必要的关联
表示方式⌗
领域模式⌗
实践 MODEL-DRIVEN DESIGN⌗
隔离领域：引入应用层⌗
应用 LAYERED ARCHITECTURE 把领域层划分出来，通过应用层类来处理应用程序功能。应用层类是协调者，负责提问，领域层负责回答。
将 ENTITY 和 VALUE OBJECT 区分开⌗
依次考虑对象是必须跟踪的 ENTITY 还是表示一个 VALUE OBJECT。
AGGREGATE 边界⌗
识别模型中的 AGGREGATE 根和对应的边界。
选择 REPOSITORY⌗
为 AGGREGATE 根对象建立 REPOSITORY。
场景走查⌗
根据应用程序特性复核建模，进行场景走查，确保能够有效地解决应用问题。可以走查一些正常和异常业务场景进行复核。
对象创建⌗
如果对象复杂则创建单独的 FACTORY 类进行对象创建，简单对象可以直接在 AGGREGATE 根上通过 FACTORY METHOD 进行创建。
停一下，重构⌗
建模和设计需要经常进行重构：利用新知识来改进模型和设计。
MODULE 划分⌗
应该按照对象的意义来划分，其他任何划分方式都是错误的，包括：
- 按模式划分
- 按照对象生命周期划分
通过重构发现深层模型⌗
重构不应该停留在代码细节层面，还应当在模型设计层面随着对知识吸收的加深对模型进行重构，发现深层模型。
深层模型能够穿过领域表象，清楚地表达出领域专家们的主要关注点以及相关的知识。
深层模型/柔性设计⌗
在不断重构的过程中，设计本身也需要支持重构所带来变化。设计自身的某些特性就可以使其易于修改和使用。 每次对模型和代码所进行的修改能够反映出对领域的新理解，不断的重构能给系统最需要修改的地方增添灵活性， 并能找到简单快捷的方式来实现普通的功能。
「戴久的手套在手指关节处变得柔软；而其他部分已然硬实，可起到保护的作用。」反复的修改能让我们越来越接近柔性设计。
柔性设计除了便于修改，还有助于改进模型本身。MODEL-DRIVEN DESIGN 需要以下两个方面支持：
- 深层模型使设计更具表现力；
- 同时，当设计的灵活性可以让开发人员进行实验，而设计又能清晰的表达出领域含义时，能够将开发人员的深层理解反馈到整个模型发现的过程中。
这应该是构建系统的基础。
发现过程⌗
支持不断重构、借用别人已经建好的模式。
突破⌗
重构创造机遇⌗
关注根本：不要强行突破⌗
概念挖掘⌗
倾听语言⌗
倾听领域专家的语言，思考并表达，观察领域专家的表情，判断自己是否找到了正确的概念（对象）。
检查不足之处⌗
积极与领域专家沟通，寻找丢失的概念。（注意领域专家的表情）
思考矛盾之处⌗
矛盾可以合理存在，但是一定要仔细思考两种对立的看法是如何同时应用于同一个外部实现的，这会给我们带来启示。
查阅书记⌗
通过解释基本概念和传统思想的书籍来寻找概念。
尝试，再尝试⌗
为隐式概念建模⌗
显式的约束⌗
约束通常式隐含的，将它们显式的表现出来可以极大地提高设计质量。约束有时自然的存在于对象或方法中。
将过程建模为领域对象⌗
建模方式：
- 通过 模式：SERVICE 显式表达。
- 通过 STRATEGY 表达选择过程：选择变成选择不同的对象，不同对象表示不同的 STRATEGY。