DDD原著 -- 第二章 语言的交流和使用

一个团队，一种语言！

1. 语言，术语的统一很重要。如果语言支离破碎，项目必将遭遇严重问题。 讨论与写代码中术语不一致，甚至同一个人说的跟写时不一致，导致对领域有一定的理解认识，也转眼忘记，无法记录到代码与文档中。
2. 项目需要一种公共语言，领域模型可以成为这种语言的核心。公共语言是整个团队工作中的通用语言（Ubiquitous Language）。
3. Ubiquitous Language的词汇表包括类名称和主要操作。
4. 模型之间的关系成为所有语言都具有的组合规则。词和短语的意义反映了模型的语义。术语=>规则、大比例结构、ContextMap
5. 知识消化 –> 模型完善 –> 术语意义改变或新术语增加
6. 将模型作为语言的重心，确保团队在所有交流活动中坚持使用这种语言。画图、写东西、讲话… 需要解决术语混淆的问题及有歧义的不一致的地方。Ubiquitous Language以动态形式传递知识。
7. 精华模型的最佳方式之一就是通过对话来研究，找出可能的模型变化，并说出对他的多种构想。这样不完善的地方很容易被听出来。
8. 讨论系统时需要结合模型。使用模型的元素以及模型中各元素之间的交互大声描述场景，并且按照模型允许的方式将各种概念结合到一起。找到更简单的表达方式来讲出你要讲的话，然后将这些新的思想应用到图和代码中。
9. UML有时过于细致，有时很多遗漏。
10. 图是一种沟通和解释手段。（简洁的小图可以很好的实现这目标）
11. 图和文档能够引导人们将注意力放在核心要点上。通常的做法是以图为主，辅以文本注释。而我更喜欢以文本为主，添加精心挑选的简化图作为注释。
12. 务必要记住模型不是图。图的目的是帮助表达和解释模型。（代码可以充当设计细节的存储库，清晰的代码与UML具有同样的表达能力。）
13. 文档只是作为代码和口头的交流的补充。但代码作为一种设计文档，自身也存在局限性。他能把读代码的人淹没在细节中。
14. 文档不应再重复表示代码已经明确表达出的内容。应着重说明含义，以便使人们能够深入理解大比例结构，并将注意力集中在核心元素上。
15. Ubiquitous Language可使文档更简洁和明确。
    当领域模型反映了与业务最相关的知识时，应用程序的需求成为该模型内部场景而Ubiquitous Language可用于描述这样一个直接与Model-Driven Design有关的场景。结果就是规格说明等文档的编写更加简单，t因为他们不必传达模型背后隐含的业务知识。
16. 通过将文档减至最少，并且主要用它来补充代码和口头交流，就可以避免文档与项目脱节。根据Ubiquitous Language及其演变来选择那些需要保持最新并与项目活动紧密交互的文档。
17. XP完全依赖可执行代码和代码测试。但方法名称可能会有歧义，会产生误导或者因为已经过时而无法表示方法的本质含义。消除歧义是声明式设计。要使代码所传达的消息与他的行为和意图保持一致，要有严格的设计规程和特定的思考方式。
18. 解释性模型不等于对象模型（技术模型）。 技术模型必须经过严格的精简，以便用最小的模型来实现其功能。 解释性模型可引入其他视图、工具等，只是为传递一般领域知识的教学工具。