DDD领域驱动设计-通用语言（UBIQUITOUS LANGUAGE）

一时失言乱红尘 2022-11-14 00:53 212阅读 0赞

### 一个团队，一种语言 ###

技术人员通常认为业务专家最好不要接触领域模型，他们认为:

“领域模型对他们来说太抽象了。”

“他们不理解对象。”

“这样我们就不得不用他们的术语来收集需求。”

上面只列举了我从一个使用两种语言的团队中听到的少数几个原因。忘掉它们吧。 当然，设计中有一些技术组件与领域专家无关，但模型的核心最好让他们参与。过于抽象?那你怎么知道抽象是否合理?你是否像他们一样深入理解领域?有时，某些特定需求是从底层用户那里收集的，他们在描述这些需求时可能会用到一小部分更具体的术语，但领域专家应该能够更深入地思考他们所从事的领域。如果连经验丰富的领域专家都不能理解模型，那么模型一定出了什么问题。

最初，当用户讨论系统尚未建模的未来功能时，他们没有模型可供使用。但当他们开始与开发人员一起仔细讨论这些新想法时，探索共享模型的过程就开始了。最初的模型可能很笨拙且不完整，但会逐渐精化。随着新语言的演进，领域专家必须付出更多努力来适应它，并更新那些仍然很重要的旧文档。

当领域专家使用这种语言互相讨论，或者与开发人员进行讨论时，很快就会发现模型中哪些地方不符合他们的需要，甚至是错误的。另一方面，模型语言的精确性也会促使领域专家(在开发人员的帮助下)发现他们想法中的矛盾和含糊之处。 开发人员和领域专家可以通过一步一步地使用模型对象来走查场景，从而对模型进行非正式的测试。每次讨论都是开发人员和专家一起使用模型的机会，在这个过程中，他们可以加深彼此的理解，并对概念进行精化。

领域专家可以使用模型语言来编写用例，甚至可以直接利用模型来具体说明验收测试。

有时，有人会反对使用模型语言来收集需求。毕竟，难道需求不应该独立于实现它们的设计吗?这种观点忽视了所有语言都要基于某种模型这一事实。词的意义是不明确。领域模型通常是从领域专家自己的术语中推导出来的，但已经经过了“清理”，以便具有更明确、更严密的定义。

当然，如果这些定义与领域公认的意义有较大差别，领域专家应该反对。在敏捷过程中，需求是随着项目的前进而演变的，因为几乎不存在现成的知识可以充分说明一个应用程序。用精化后UBIQUITOUS LANGUAGE来重新组织需求应该是这种演变过程的一部分。

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

当然，开发人员的确会使用领域专家无法理解的技术术语。开发人员有其所需的大量术语来讨论系统技术。几乎可以肯定的是，用户也会用开发人员无法理解的、超出应用程序范畴的专用术语。这些都是对语言的扩展。但在这些语言扩展中，同一领域的相同词汇不应该反映不同的模型。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb3hpbjk2Mw_size_16_color_FFFFFF_t_70][]

有了UBIQUITOUS LANGUAGE之后，开发人员之间的对话、领域专家之间的讨论以及代码本身所表达的内容都基于同一种语言，都来自于一个共享的领域模型。

***DDD落地方案QQ交流群：130950009，群里会不定期的推荐好的DDD文章，讨论DDD落地方案和xtoon-boot框架（开源地址：[https://gitee.com/xtoon/xtoon-boot][https_gitee.com_xtoon_xtoon-boot]），期待您加入交流！***

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb3hpbjk2Mw_size_16_color_FFFFFF_t_70]: /images/20221022/32e05693c4e24650959dca7d9fe4c78c.png
[https_gitee.com_xtoon_xtoon-boot]: https://gitee.com/xtoon/xtoon-boot