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

2015-06-29

第二章 语言的交流和使用

模式： UBIQUITOUS LANGUAGE(通用语言)

开发在于领域专家沟通时，需要建立一个通用语言，来减少沟通的成本

基于业务，开发和业务达成共识，用双方都能理解的黑话来讨论序曲

强调了专业术语的差异，带来沟通和理解的成本，为了降低成本，必须使用一种共同的术语来建模。

这个术语更偏重于业务，而不是开发，但开发对于术语所代表的意义和业务要达成共识。

领域语言在描述业务场景或者是构建领域模型时，如果有歧义，则需要领域专家向开发人员澄清，清除歧义，同时也会更新模型。

通用语言的包括口头的交流语言，图表，文档。

书面文档，不是必须的，但它可以作为口头交流的补充，文档是基于领域模型的，不是对代码的复述。

书面文档如果不再被及时的更新，那么它就失去存在的意义，请把它归档。

所以书面文档请保持尽量的简洁

文字和图是相辅相成的，不要刻意的去偏重某一种描述。

代码是最实时有效的对模型的描述，但它太偏重与细节，不是能被领域专家所能完全理解的，即便领域专家能理解，但会让人深陷细节中。

所以需要文档作为补充。

图不完全是UML图，可以用简单的图示去描述业务流程，更适用与沟通。

本章更多是在强调用一种双方都便于理解的语言、文字和图去对系统进行描述，便于大家对系统的分析和设计。