domain-driven-design - 与领域专家一起建模领域的最佳方式

Question

我做了相当多的分析，并使用了许多工具来捕获需求:用户创建的 Storyboard、用例、GUI 图纸、GUI 原型(prototype)、可用作验收标准的用户故事和场景等。

虽然每一个都有或多或少的优点，但我认为缺少一个重要的部分。这些方法可以准确地捕捉用户如何与您的应用程序交互，但由程序员来创建和开发应该反射(reflect)在代码中的“模型”。

我一直在阅读Evan’s DDD最近，他提出了一些不同的建议。您需要与领域专家一起创建领域模型并与他共享。为了与用户交流思想，他在书中经常使用特别受UML启发的绘图。

我想知道这是否是与领域专家讨论模型的最佳方式。除了 UML 图，还有其他工具可以用来捕获领域知识并在与领域专家讨论领域时使用它吗？

Answer 1

虽然最终抽象为工作域模型(最终是稳定模型)是您(开发人员)的工作，但我同意即使是上面的工具集也可能会受到限制，并且将您自己或您的通信限制为仅使用 UML 可以使对话对领域专家来说似乎很深奥。

对于系统剖析，请尝试 http://www.fmc-modeling.org/ 上的框图符号工具。 .

对于白板/黑板和思维导图，请尝试 FreeMind

对于联想组织(和冷静)，试试 TheBrain

为了更快/协作图形(有点新)，请尝试 LucidChart

当然，好的 ol' Dictionary 和同义词库要始终、始终争取最好的术语。

如果这些对您来说似乎是右脑思维，请记住建模是由一方代表两方进行的左脑分析。纯粹定义的线性过程与试错、自由运行的信息挖掘相结合时，你不会得到那么多。