领域驱动设计-软件核心复杂性应对之道

每个软件程序是为了执行用户的某项活动，或是满足用户的某种需求。

这些用户应对软件的问题区域就是软件的领域。

---

领域模式并非某种特殊的图，而是这种图所要传达的思想。它绝不单单是领域专家头脑中的知识，而是对这类知识严格的组织且有选择的抽象。图可以表示和传达一种模型，同样，精心书写的代码或文字也能达到同样的目的。

领域建模并不是要尽可能建立一个符合”现实”的模型。即使是对具体、真实世界的事物进行建模，所得到的模型也不过是对事物的一种模拟。它也不单单是为了实现某种目的而构造出来的软件机制。建模更像是制作电影–出于某种目的而概括的反映现实。

---

模型在领域驱动设计中的作用

1. 模型和设计的核心互相影响
2. 模型是团队所有成员使用的通用语言的中枢
3. 模型是浓缩的知识

---

软件的核心

软件的核心是其为用户解决领域相关的问题的能力。

所有其他特性，不管有多么重要，都要服务于这个基本目的。

当领域很复杂时，这是一项艰巨的任务，要求高水平技术人员的共同努力。

---

有效建模的要素

1. 模型和实现的绑定
2. 建立一种基于模型的语言
3. 开发一个蕴含丰富知识的模型
4. 提炼模型
5. 头脑风暴和实验

---

知识消化

高效的领域建模人员是知识的消化者。它们在大量信息中探寻有用的部分。不断尝试各种信息组织方式，努力寻找对大量信息有意义的简单视图。很多模型在尝试后被放弃或改造。只有找到一组适用于所有细节的抽象概念后，工作才算成功。

知识消化并非一项孤立的活动，它一般是在开发人员的领导下，由开发人员与领域专家组成的团队来共同协作。他们共同收集信息，并通过消化而将它组织为有用的形式。信息的原始资料来自领域专家头脑中的知识、现有系统的用户，以及技术团队以前在相关遗留系统或同领域的其他项目中积累的经验。信息的形式也多种多样，有可能是为项目编写的文档，有可能是业务中使用的文件，也有可能来自大量的讨论。早期版本或原型将经验反馈给团队，然后团队对一些解释做出修改。

在团队所有成员一起消化理解模型的过程中，他们之间的交互也会发生变化。领域模型的不断精化迫使开发人员学习重要的业务原理，而不是机械的进行功能开发。领域专家被迫提炼自己知道的重要知识的过程往往也是完成其自身理解的过程，而且他们会渐渐理解软件项目所必须的概念严谨性。

模型在不断改进的同时，也成为组织项目信息流的工具。模型聚焦于需求分析。它与编程和设计紧密交互。它通过良性循环加深团队成员对领域的理解，使他们更透彻的理解模型，并对其进一步精化。它们必须非常精确，以便使应用程序易于实现和理解。

---

Ubiquitous Language

开发人员应该使用基于模型的语言来描述系统中的工件、任务和功能。

这个模型应该为开发人员和领域专家提供一种用户相互交流的语言，而且领域专家还应该使用这种语言来讨论需求、开发计划和特性。语言适应的越普遍，理解进行的就越顺畅。

将模型作为语言的支柱。确保团队在内部的将所有交流中以及代码中坚持使用这种语言。

在画图、写东西，特别是讲话时也要使用这种语言。

通过尝试不同的表示方法（它们反映了备选模型）来消除难点。然后重构代码，重新命名类、方法和模块，以便于新模型保持一致。解决交谈中的术语混淆问题，就像我们对普通词汇形成一致的理解一样。

领域专家应该抵制不合适或无法充分表达领域理解的术语或结构，开发人员应该密切关注那些将会妨碍设计的有歧义和不一致的地方。

讨论系统时要结合模型。使用模型元素及其交互来大声描述场景，并且按照模型允许的方式将个各种概念结合到一起找到更简单的表达方式来讲出你要讲的话，然后将这些新的想法应用到图和代码中。

---

Model Driven Design

如果整个程序设计或者其核心部分没有与领域模型相对应，那么这个模型就是没有价值的，软件的正确性也值得怀疑。同时，模型和设计功能之间过于复杂的对应关系也是难于理解的，在实际项目中，当设计改变时也无法维护这种关系。若分析和设计之间产生严重分歧，那么在分析和设计活动中所获得的知识就无法彼此共享。

软件系统各个部分的设计应该忠实的反映领域模型，以便体现出这两者之间的明确对应关系。我们应该反复检查并修改模型，以便软件可以更加自然的实现模型，即使想让模型反映出更深层次的领域概念时也应如此。我们需要的模型不但应该满足这两种需求，还应该能够支持健壮的通用语言。

从模型中获取用于程序设计和基本职责分配的术语。让程序代码成为模型的表达，代码的改变可能会是模型的改变。而其影响势必要波及接下来相应的项目活动。

完全依赖模型的实现通常需要支持建模范式的软件开发工具和语言，比如面向对象的编程。

---

Hands On Modeler

如果编写代码的人员认为自己没有必要对模型负责，或者不知道如何让模型为应用程序服务，那么这个模型就和程序没有任何关联。如果开发人员没有意识到改变代码就意味着改变模型，那么他们对程序的重构不但不会增强模型的作用，反而还会削弱它的效果。同样如果建模人员不参与到程序实现的过程中，那么对程序实现的约束就没有切身的感受，即使有，也会很快忘记。Model Driven Design的两个基本要素（即模型要支持有效地实现并抽象出关键的领域知识）已经失去了一个，最终模型将变得不再实用。最后一点，如果分工阻断了设计人员与开发人员之间的协作，使他们无法转达Model Driven Design的种种细节，那么经验丰富的设计人员则不能将自己的知识和技术传递给开发人员。

任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度的参与模型讨论并且与领域专家保持联系。参与 不同工作的人都必须要有意识的通过Ubiquitous Language来接触代码的人及时交换关与模型的想法。