Dan*_*Dan 5 uml modeling domain-driven-design
我做了一些分析,并使用了许多工具来捕获需求:用户创建的故事板,用例,GUI绘图,GUI原型,可用作验收标准的用户故事和场景等.
虽然每个都有或多或少的优点,但我认为有一个重要的缺失.这些方法可以准确地捕获用户与您的应用程序交互的方式,但是程序员需要创建和开发应该反映在代码中的"模型".
我最近一直在阅读Evan的DDD,他提出了不同的建议.您需要与域专家一起创建域模型并与他共享.为了与用户交流想法,他在书中经常使用ad-hoc UML启发的绘图.
我想知道这是否是与领域专家讨论该模型的最佳方式.除了UML图之外,还有其他任何工具可用于捕获领域知识并在您与域专家讨论域时使用它吗？
虽然工作域模型（最终是稳定的模型）的最终抽象是您（开发人员）的工作，但我确实同意，即使上面的工具集也可能会受到限制，并且将您自己或您的通信限制为仅 UML 可以使对于领域专家来说，对话似乎很深奥。
对于系统剖析，请尝试http://www.fmc-modeling.org/上的框图符号工具。
对于白板/黑板和思维导图，请尝试 FreeMind
对于关联组织（和酷），请尝试 TheBrain
要更快/协作绘图（有点新），请尝试 LucidChart
当然，优秀的词典和同义词库始终致力于提供最好的术语。
如果这些对您来说似乎是右脑思维，请记住建模是由一方代表两人完成的左脑分析。通过纯粹定义的线性过程，您不会得到与试错、自由运行式信息挖掘相结合的那么多结果。