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

BIQUITOUS LANGUAGE（通用语言）的词汇包括类和主要操作的名称。将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言。解决交谈中的术语混淆问题，就像我们对普通词汇形成一致的理解一样。要认识到，UBIQUITOUS LANGUAGE的更改就是对模型的更改。领域专家应该抵制不合适或无法充分表达领域理解的术语或结构，开发人员应该密切关注那些将会妨碍设计的有歧义和不一致的地方。

2.2 “大声地”建模

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

2.3 一个团队，一种语言

语言的多样性通常是必要的，但领域专家与开发人员之间不应该有语言上的分歧

2.4 文档和图

图是一种沟通和解释手段，它们可以促进头脑风暴。

设计的重要细节应该在代码中体现出来。

互为补充的图和文档能够引导人们将注意力放在核心要点上。务必要记住模型不是图。图的目的是帮助表达和解释模型。

2.4.1 书面设计文档

文档应作为代码和口头交流的补充.

极限编程主张完全不使用（多余的）设计文档，而让代码解释自己。文档不应再重复表示代码已经明确表达出的内容。

设计文档的最大价值在于解释模型的概念，帮助在代码的细节中指引方向，或许还可以帮助人们深入了解模型预期的使用风格。

文档必须深入到各种项目活动中去。

2.4.2 完全依赖可执行代码的情况

尽管代码可能会产生误导，但它仍然比其他文档更基础。

2.5 解释性模型

解释性模型提供了一定的自由度，可以专门为某个特殊主题定制一些表达力更强的风格。

三、绑定模型和实现

3.1 模式：MODEL-DRIVEN DESIGN

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

MODEL-DRIVEN DESIGN（模型驱动设计）不再将分析模型和程序设计分离开，而是寻求一种能够满足这两方面需求的单一模型。

软件系统各个部分的设计应该忠实地反映领域模型，以便体现出这二者之间的明确对应关系。

3.2 建模范式和工具支持

面向对象编程之所以功能强大，是因为它基于建模范式，并且为模型构造提供了实现方式。

3.3 揭示主旨：为什么模型对用户至关重要

如果程序设计基于一个能够反映出用户和领域专家所关心的基本问题的模型，那么与其他设计方式相比，这种设计可以将其主旨更明确地展示给用户。

3.4 模式：HANDS-ON MODELER

HANDS-ON MODELER（亲身实践的建模者）并不意味着团队成员不能有自己的专业角色。

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

将建模和编程过程完全分离是行不通的，然而大型项目依然需要技术负责人来协调高层次的设计和建模，并帮助做出最困难或最关键的决策。