读《领域驱动设计》心得分享（一）：激活模型的力量

《领域驱动设计》读书笔记第一部分的读书笔记，主要讲领域驱动设计的基础理论，和基本的团队实践原则。

第一部分 让模型发挥作用

引子

1 DDD中模型的作用

1. 模型与设计核心的相互塑型 模型驱动了设计，最终产生和模型绑定的代码；用代码实现模型时又发现问题，反作用于模型。 2. 模型是所有团队成员所使用的语言的核心 团队成员在交流过程中用统一的语言围绕模型进行交流。由于模型和代码之间的绑定关系，讨论模型就是在讨论程序；又由于模型是对于业务分析而来的，所以讨论模型也就是在讨论业务。实现开发人员和业务人员之间的无障碍沟通。 3. 模型用来提炼知识。不断地改进模型，可以加深我们对领域的认识，发现领域深层次的问题，这些将成为我们在该领域的知识，这些知识被模型承载，并通过学习模型传承下去。

2 软件的核心

软件的核心是它为用户解决领域相关问题的能力。其他的一些特征，尽管它们也许是必需的，但也是用来支持这个核心目的的。但是很可惜，开发人员往往不懂领域，而领域专家也不懂程序。领域驱动设计方法，就是要找到一个中间的桥梁，让开发人员和领域专家可以沟通，让程序和领域相绑定。这个桥梁就是领域模型。

第1章 消化知识

1.1 有效建模的因素

领域模型源自于开发人员和领域专家的交流和共同学习的过程，有效的领域模型具备以下一些因素： 1. 模型与实现相互绑定。不能应用于实现在模型，是没有意义的。 2. 基于模型生成一种语言（用于交流的语言，不是指形式化的计算机语言）。如果不能生成一种语言来描述模型，沟通交流将难于持续下去。 3. 开发了一个包含丰富知识的模型。模型是包含了丰富的状态和行为了，这些状态和行为体现了这个领域的知识。 4. 提炼模型。模型需要不断的改进，因为很难一次性成功的找到领域的模型，而且领域自身也在不断的变化。

1.2 知识消化

1.3 持续学习

1.4 知识丰富的设计

1.5 深层模型

第2章 交流及语言的使用

面对面的交流是最有效了，在交流的过程中设计模型，形成团队自己的描述模型的语言，让这个语言没有歧义。

2.1 通用语言

当一个项目的语言存在断层时，会面临一系列的问题。领域专家使用自己的行话，而技术团队成员却按照设计思路调整和使用自己的语言去讨论领域。 天天进行讨论时所使用的术语与嵌入到代码（一个软件项目最重要的最终产品）中的术语是分裂开来的。甚至可能是同一个人，在编写文档或者代码时，也会使用跟交流讨论时完全不同的语言，这会导致对于领域的某些深入描述只是短时间内存在，却无法反映到代码或者文档编写中。 语言转换减弱了交流的效果，使得知识积累也不尽如人意。 然而任何一种方言都不能够成为通用语言，因为它们都无法满足所有需求。 要将模型作为语言的骨干。团队在所有的交流与代码中都应该练习使用这种语言。在图、文档编写，尤其是发表意见过程中都使用相同的语言。 通过用替代表达方法进行实验来消除实际中遇到的困难，它们反映了替代模型的含义。然后按照新的模型重新进行编码，并对类、方法和模块进行重命名。在交谈中辨明术语中含糊的词义，就像我们对普通的词语意义达成一致意见那样。 要意识到通用语言中的变化也是模型中的变代。 领域专家应该排除掉传达领域意思时不易使用或不适当的术语或结构；开发人员应该注意防止可能导致设计失败的模糊性或不一致性。

2.2 利用对话改进模型

结合模型来讨论系统。使用模型的元素和元素之间的交互来大声描述场景，按照模型允许的方式把概念组合在一起。找到更简单的方式来说出要表达的内容，然后将这些意见应用到图形和代码中。

2.3 一个团队，一种语言

2.4 文档和图

文档和图用来描述在代码难中以被描述的高层次的模型的意义和目的，而代码则是对模型最细节的描述。代码能够描述得清楚的事情，就不需要文档和图来描述。

2.5 说明性模型

第3章 将模型和实现绑定

3.1 模型驱动设计

如果一个设计，或者它的核心部分，不能够映射到领域模型上，那这个模型是没有价值的，软件的正确性也是值得怀疑的。同时，模型与设计功能之间复杂的映射常常难于理解，并且在实践中，当设计发生变化的时也不可能维护。在分析与设计之间存在致命的隔阂，从任何（分析和设计）活动中获得的知识都无法提供给另一方。 应该设计出能够非常精确地反映领域模型的部分软件系统，这样映射就会明显。如同您尽力让模型更深层次地反映领域一样，再次研究模型并修改，使得它能够让软件更加自然地实现。需要这样的单个模型，除了要支持一种健壮的通用语言之外，还要很好地完成这两个目的。 从模型中得到的术语可以用于设计和职责的基本分配。代码成为模型的表达形式，因此对代码的改变可能也变成对模型的一种改变。它的影响将相应波及到项目中的其他活动。

3.2 建模范型和工具支持

过程化的程序语言，如C，往往缺少足够的抽象能力来让程序和领域直接对应，而是迫使程序员思考让计算机做一系列的什么样的操作过程来完成任务。要将实现与模型严格地绑定在一起，通常需要支持建模范型的软件开发工具和语言，例如面向对象的编程。

3.3 突出主旨：为什么模型对用户很关键

让用户理解模型，用户能更好的使用程序。

3.4 实践型建模人员

如果编写代码的人认为他们不对模型负责，或者并不理解如何让模型在一个应用程序中发挥作用，那么模型对于软件来说根本就没有用。如果开发人员没有意识到改变代码会同时改变模型，那么他们的重构工作只会减弱模型的作用而不是增强。其间，当一个建模人员与实现过程相分离的时候，他／她永远不会学会（或者说是错过了）对实现上的一些约束的感觉。模型驱动设计的基本约束——模型要支持高效的实现和模型要抽象关键的领域知识——已经丢失了一半，最终的模型变得不再实用。最后，如果分工阻碍了协作，在对模型驱动设计进行编码时，不能传递细节，那么经验丰富的设计人员的知识和技术不能够传递给其他的开发人员。 负责建模的技术人员必须花时间接触代码，而不论他或她是否在项目中担当主要角色。任何负责代码修改的人员都要学习通过代码表达模型。每个开发人员都必须参与一些级别的模型讨论中，并与领域专家接触。负责不同工作的人员都必须自觉地和接触代码的人交流，通过通用语言动态交换模型想法。