与领域专家一起进行领域建模的最佳方式

Question

我做了相当多的分析，并使用了许多工具来捕获需求：用户创建的故事板、用例、GUI 绘图、GUI 原型、用户故事和示例。可以用作验收标准等的场景。

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

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

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

Answer 1

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

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

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

对于关联组织（和酷），请尝试 TheBrain

对于更快/协作绘图（有点新），请尝试 LucidChart

当然，还有很好的字典和同义词库，总是< /em> 争取最好的术语。

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

Answer 2

最好的方法是铅笔和纸。 UML 以及此后不会出现的内容。从 DSL（谈论领域时使用的词汇列表）开始。然后，您可以使用该列表来确定实际是什么（模型、聚合、操作[动词]等），然后您可以进行关联。

之后，绘制 UML 图并与领域专家一起检查。如果他们理解了，那么你就是黄金。

这本书涵盖了完全按照我所说的去做。我建议至少浏览一下这本书（实际上我不知道你是否在使用.NET）。 http://www.amazon.com/Professional-Refactoring-ASP-NET-Wrox-Programmer/dp/047043452X/ref=sr_1_1?s=books&ie=UTF8&qid=1306529986&sr=1-1

Answer 3

您可以使用大量的工具：

• 参与者地图
• 参与者表业务
• 策略业务
• 规则
• 上下文图
• 决策表或决策树
• 域模型
• 事件表
• 流程图
• 场景
• 状态图
• 用例
• 思维导图
• ..

有太多又长又无聊 的工具关于他们每个人的书。有些工具在某些环境下工作“最好”，而在其他环境下“可能失败”。没有什么比“最好”更好的了：环境很重要。

但重要的不是技术本身：重要的是你如何应用它们......
。

诀窍在于如何与客户-领域专家-最终用户“协作”。
协作研讨会通常在许多情况下效果最好。下面这本书在这方面做得很好。

协作要求：定义需求研讨会，Ellen
戈特斯丁纳

检查 http://ebgconsulting.com/facassets.php

但要小心不要成为模板僵尸 [这是需求领域的常见疾病]

您甚至可以使用游戏来进行更好的协作：

创新游戏：通过协作创造突破性产品
播放，卢克·霍曼

Answer 4

领域专家往往比其他任何事情都更能理解句子。这就是为什么我喜欢对象角色建模。很多开发都与图形方法有关，但在实践中，我发现仅使用结构化句子效果最好。

Answer 5

我个人发现最有效的方法是坐下来即时编写领域模型，同时经常向坐在我旁边的领域专家询问是/否问题。仅当您的编码速度足够快时，这才有效。

---

另外，用通用语言构建的思维导图（树应该读起来像句子）是很好的沟通方式。也易于创建、共享和理解。

真实世界的示例：（

Payment
    comments
        can be edited
            if user is authorized
                with role [Role]
    can be approved
        if user is authorized
        if payment is initiated
        if payment is not paid yet
        if amount does not exceed allowed budget
    when approved
        remembers that
        saves approving date
    can be rejected
        if something something...
    when rejected
        forgets planned pay date
        resets amount to be paid

如果您想在 text2mindmap 工具）

翻译为：

public class Payment{
    public virtual void EditComments(string comments){
        Authorize<EditPaymentComments>();
        CommentsEntered=true;
        CommentsEditedBy=User;
        CommentsEditedOn=SysDateTime.Now();
        Comments=comments;
    }
    public virtual void Approve(){
        EnsureCanBeApproved();
        IsApproved=true;
        ApprovedOn=SysDateTime.Now();
        Raise(new Approved(this));
    }
    protected virtual void EnsureCanBeApproved(){
        Authorize<AcceptPayments>();
        ThrowIf(!IsInitiated,
            "Payment is not initiated.");
        ThrowIf(IsPaid,
            "Payment is already paid.");
        ThrowIf(ExceedsAllowedBudget(ToBePaid),
            "Amount to be paid exceeds allowed budget.");
    }
    public virtual void Reject(){
        EnsureCanReject();
        ForgetPlannedPayDate();
        ToBePaid=0;
        IsInitiated=false;
        IsRejected=true;
        Raise(new Rejected(this));
    }
    private void ForgetPlannedPayDate(){
        Deadline=DateTime.MinValue;
        DeadlineKnown=false;
    }
}

Answer 6

到目前为止，对于工具有很多好的建议。尝试它们并使用您喜欢的那些，但成功的关键是代码和对话之间的迭代...埃文斯称之为知识处理。您倾听领域专家的意见越多，对您在代码中听到的内容进行建模，然后向他们展示软件，获得反馈并调整模型，您就越接近解决手头问题的软件。

Answer 7

对我来说，这取决于领域专家。

对于某些人来说，这只是在白板上绘制 UI 草图 - 展示它在屏幕上的外观 - 然后提出以下问题：“如果没有那个，这个可以存在吗？”，“您是否遇到过这个是第一个的情况稍后添加，或者它们总是在那里”、“您希望它们填写哪个顺序？”、“谁需要从这个屏幕上知道什么？”...通常，视觉辅助工具可以帮助他们让他们能够非常准确地回答你的问题。

其他人，我可以使用朴素的 UML（显示聚合、值类型、属性和集合），他们对此很满意。

真的，对我来说这很简单，我从简单开始——不断添加技术性的东西，直到他们眼前一片空白——然后退一步。并且始终有某种起始位置来让创意源源不断。如果您遇到困难，只需观察他们的工作 - “等一下 - 你为什么不记录这些信息？”，“哇，你在那里做了什么？” - 对我来说，这些工具只是为了帮助我，它们很少帮助领域专家。

基本上，除了笔和纸（如果可能的话，还有白板）之外，几乎不需要任何工具来处理知识。

Answer 8

我所做的就是为需求创建用例图。我可以在模型级别保存所有需要的信息。我的用例图可以保存我必须建模的几乎所有复杂的所需系统。

我还可以在多个图中重复使用相同的用例，并且仍然保留其属性。确实技术精湛。

关于 UML 领域，我在同一个图中取消了用例和类图元素，并添加了一个数据库配置文件，这允许我在类图中添加持久性。因此，这是具有数据库规范的对象建模。

我的建模非常复杂，我创建了数据库，并且可以永久重构我的需求并立即重构我的代码，而不会丢失我的模型。

我每天都使用它并且非常喜欢它。
希望这有帮助。