构建更好的软件：领域叙事在领域驱动设计中的作用

靠著一份需求列表開始新項目的日子已經一去不復返了。你手頭的只是一些試圖解釋系統預期功能和限制的文字。對於即將解決的問題，你沒有任何理解，或你項目旨在緩解的用戶困難，你完全不了解。

无需DDD的方法解决问题

这些项目通常会引发与产品团队的来回沟通，试图真正理解产品需要的功能并找出可能的边界情况，最终导致低效的会议和时间的浪费。

这就是领域驱动设计试图解决的软件世界中的问题。DDD是一套有效解决业务问题的方法，并能够通过高效的业务软件解决问题。

在这篇文章里，我不会向你解释DDD是什么，因为我假设如果你正在读这篇文章，你已经对DDD有一定的了解了。通过DDD，前面提到的场景看起来完全不同。DDD的目标是让所有领域专家都用同一种语言（即通用语言）交流，并共享对问题的理解。这样一来，你就可以直接跟其他利益相关者、项目经理、业务分析师等用一种大家都懂的共同语言沟通了。

用领域驱动设计解决问题

共享模型，也就是我们所说的领域模型，基本上是公司不同领域专家之间共享的知识。这个模型涵盖了用户遇到的问题，共同的语言，以及我们对用户感受与理解与他们面临的问题。

这种共享语言被称为“Ubiquitous Language”，是通过会议共同讨论术语和不同利益相关者的观点而实现的，它将成为你领域建模的基础。

什么是无处不在的语言的定义

在团队拥有一个共同语言之后，领域叙事此时才真正开始发挥作用。领域叙事是一种将领域知识转化为业务软件的协作方法。它将来自各利益相关者的知识转化为实体、关系、上下文等，并最终变成代码。

让我们着手解释如何在公司遇到的任何特定问题中实施领域讲述的方法。

第一步当然是召集所有相关方到一个房间里或是在线上通话，以便你们一起开始绘制草图和图表。一旦所有人都在同一个房间里，你应该开始分享你的观点和对问题的理解，这样其他人也能更好地了解情况。

接下来，我们开始画图部分。但这并不是任何种类的绘图，我们不想从受数据库关系或编程语言影响的技术图开始绘制。我们开发者已经有了用来绘制图的语言，UML是个很好的建模语言，但这可能会让产品团队的人感到无聊，因为他们可能对这些技术图并不感兴趣。你希望用一种所有人都能理解的方式来表达这个流程，从商业分析师到项目经理。而你要通过讲故事的方式来描绘这个“画布”。没错，你希望用讲故事的方式来描述这个流程（例如，用户去超市买了一袋土豆，然后去收银台结账）。

这些故事是根据我将要教你们如何绘制的图表创建的。这些图表使用一系列特定的符号，这些符号共同构成了所谓的“图像语言”。这种语言由四个元素构成。

• 一个“行动者”
• 一个“操作对象”
• 一个“行动”
• 一个“序列号”

简单的象形文字基本元素

所以比如说：“客户签署合同”，可以表示成：

基本要素

在象形语言中有一些规则。其中一个规则是，虽然演员能做多个动作，但他们不会重复出现。不过，每次对工作对象进行操作时，都应重复表示工作对象。

曾经的演员，他们的工作对象被复制了

另一个有点令人惊讶的指南是，在这种图形语言中，没有 if/else 结构，这使得它更像是场景驱动的语言。

基本上来说，你需要画一个图来说明你描述的具体场景。例如，你在描述一个客户如何在电影院买电影票，你可以有多种不同的情况，比如：

• 最佳情况——顺利途径
• 客户用卡支付但被拒绝的情况
• 客户支付正好金额现金的情况
• 客户支付现金超出金额的情况

你明白我的意思吧？

此外，这种象形文字是基于范围的，也就是说，它依赖于绘制图表时所使用的范围。在绘制图表之初，需要考虑三个范围。

粒度 — 图表用来表现故事的细节程度。你可以根据需要描述得尽可能详细，但细节越多，你就会得到越多的场景。

时间点 — 用于指定描述的过程中的某个时间点。你可以这样表示流程：现在的情况、过去的情况或你期望的情况等等。

领域纯粹性 — 你想要它有多数字化。让我用一个例子来解释。比如，我们再想象一下客户购买电影票的情景。一个纯粹的图示会描述用户在售票处买票的过程，而另一部分则描述用户打开电影院的网站，如何购买电影票。

现在我们已经了解了象形语言，你可以开始工作坊，并尝试处理流程中的特定环节。在开始之前，你应该讨论绘制图表时涉及的范围。

让我们来看一个实际的例子。有一天我们醒来，决定去汽车经销商看看，买辆新车。问题是你的钱包不太鼓，你付不起全款买车。因此，你需要申请一个分 X 期付款的合同。流程大致如下，会用图解来表示。

领域故事图

正如你所看到的，我们仅仅使用了上述4个元素。我们就能够描述整个流程。显然，我们没有深入细节，这只是在一个纯粹的范围内。

画完这个图后，是时候开始识别有界上下文了。在这个情况下，我们可以将其分为两个有界上下文（BC）：“风险评估”（Risk Assessment）和“销售”（Sales）。

如图所示，我们有一个工作对象“合同”，它作为一个实体，具有不同的动作。其中一个动作是投票，而另一个是签署，它们分别位于图的右边和左边。这表明两者实际上是有区别的，因此，应该在不同的上下文中分别拆分并创建它们。

合同这个实体

从这里起，你应该把这应用到所有流程中，并开始多写一些领域故事。

在纸上画图的方式如下：

例如，一个顾客在电影院买爆米花的过程可以这样描述：

请看纸张的右边，我标注了一些假设及其考虑的范围。

• 域故事讲述是一种不同于经典事件风暴的替代方法。两者有不少相似之处。更多内容请参阅 https://www.lucidchart.com/blog/ddd-event-storming
• 这只是一篇基于个人学习对这一主题的入门文章。
• 如果您想深入了解这种技术，强烈建议您阅读这本书：“域故事讲述：一种合作、可视化和敏捷的领域驱动软件开发方法”
• 本文中的一些图表和图片取自https://domainstorytelling.org/。您也可以访问他们的网站。