如何让非程序员理解领域模型

Question

在进行复杂的项目时，很多人会长期参与开发。因此，出现了如何使每个人都参与来了解域模型的问题。

在DDD之后首次开发项目时，可能会在所有人中进行充分讨论，并且经过精心设计。在这个阶段，每个人都相对容易理解并就基础领域模型达成共识。

但是，随着项目的反复进行，可能会涉及到不同的人群，但很少有人仍然可以掌握整个情况。即使代码维护得很好，包括领域专家/产品经理/测试人员在内的非程序员也很难掌握嵌入在代码中的业务规则。

我能想到的唯一出路是保持文档/项/图对每次更改都保持良好的状态，并始终反映基础模型。但是我认为这对于任何非平凡的项目都是巨大的挑战。而且很难确定文档中需要包含多少细节。

我有什么可以借鉴的最佳实践，这样人们可以很好地理解领域模型，并且可以轻松地随产品一起发展？

Answer 1

使用行为驱动开发（BDD）。

BDD就像TDD。但是BDD始终专注于测试域行为，并且使用域的 Ubiquitous Language 定义测试。所有故事/功能/场景都可以以结构化，易于阅读的形式（like this）

编写。

并且由于测试与您的代码紧密耦合，因此它们必须保持同步（假设您的团队受过纪律以确保测试保持最新）。

根据我的经验，这为以适度可读的格式公开最新域规则提供了最经济的解决方案。

Answer 2

DDD中最重要的策略是Bounded contexts。这对应于业务中的（子）域。理想情况下，他们应该一对一映射。因此，应该做的第一步是清楚地识别（子）域。这也是最难的。

人们应该绘制一幅上下文图，而不是保留很多带有很多细节的图，这些细节很难与项目保持同步。

在此之后，您已经将问题分解为更易于管理的部分。看到上下文地图，就可以在几分钟之内了解全局。

对于每个（子）域，您可以保留一个主要业务规则列表。任务管理软件（即Jira）可能是这些的唯一来源。