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

【问题标题】：How to get non-programmers to understand domain model如何让非程序员理解领域模型
【发布时间】：2019-03-07 03:36:23
【问题描述】：

在处理一个复杂的项目时，很多人会在很长一段时间内参与开发。因此，如何让每个人都参与进来理解领域模型的问题就来了。

当一个项目第一次按照 DDD 开发时，它可能在所有人中都得到了很好的讨论，并且是经过精心设计的。在这个阶段，每个人都比较容易理解并就底层领域模型达成一致。

但是，随着项目迭代的时间越来越长，可能会涉及到不同的人群，而且很少有人能掌握全貌。即使代码维护得很好，非程序员，包括领域专家/产品经理/测试人员，也很难掌握嵌入在代码中的业务规则。

我能想到的唯一出路是为每次更改妥善维护文档/umls/图表，并始终反映底层模型。然而，我认为这对于任何非平凡的项目来说都是一个巨大的挑战。而且很难决定文档中需要包含多少细节。

有没有什么我可以借鉴的最佳实践，这样域模型可以被人们很好地理解，并且也很容易随着产品的发展而发展？

【问题讨论】：

【解决方案1】：

使用行为驱动开发 (BDD)。

BDD 就像 TDD。但 BDD 始终专注于测试域行为，并且使用域的通用语言定义测试。所有故事/功能/场景都可以以结构化、人类可读的形式编写 (like this)

而且由于测试与您的代码紧密耦合，它们必须保持同步（假设您的团队有纪律地保持测试最新）。

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

【讨论】：

伙计们，不要错过这个答案。我们在许多项目中工作过，BDD 令人难以置信的是，在测试这些规则的同时，非技术用户也可以理解业务规则。用户甚至可以编写测试，迫使他们声明他们的业务模型需要的所有案例（没有更多未定义的案例！）。
听起来不错，会试一试

【解决方案2】：

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

与其保留大量的图表，其中包含很多难以与项目保持同步的细节，不如绘制一个上下文图。

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

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

【讨论】：

感谢您的回复。您能否详细说明使用 Jira 作为事实来源？我的意思是它只包含一堆变化，有点像事件源。获取当前的“快照”是不是很不方便？
@fankai 当前的“快照”是代码，但不遵循 DDD 的代码很难逆向工程成业务规则。
对不起，快照是指当前有效的业务规则。我的意思是非程序员如何掌握 Jira 当前有效的业务规则？
以 Evans 书中的货物为例，有 10% 的超额预订规则。假设 6 个月后，这将更改为 20%。这种变化确实有一个 Jira 故事，代码也相应地发生了变化。但是，假设再过一年，人们如何不检查代码就发现当前规则是 20% ？也许我们可以尝试在 Jira 中搜索，但这听起来不太准确。
@fankai 确实，搜索 Jira 不是很准确。非程序员无法理解代码，因此似乎需要单独的业务规则文档。在我现在的工作地点，老板问我，程序员，什么是业务规则，因为他忘记了，我告诉他：让我看看代码。如果我使用 DDD，很快就会得到答案。