领域故事（Domain Storytelling）起源

我并没有真正发明它，但我确实给它起了名字。实际上有几个前辈。其中一个是我加入这家公司实习时第一次学到的技术，虽然他们使用了这个技术，而且他们有一个建模工具，但这是一种有不同模型类型的企业建模方法。也有这样一种模型，它显示了小棍子，与他们所谓的工作对象一起工作。

我们和我的同事，也就是我的合著者一起，所做的就是提炼出其中的精髓，使其易于使用，没有前辈们所有的其他包袱，我们给你起了一个响亮的名字。

(Domain Storytelling)是一个关于领域的故事，关于在一个领域中发生的事情。但它也有点参考了领域驱动设计，因为我们认为，嗯，这确实是我们的关键实现。

多年来，我们一直在用这种更像大学的方法工作，并努力寻找行业中的人，在软件开发社区，谁得到了它，谁理解它。

当我们发现DDD社区时，我们说，这就是我们的社区。他们就是这样的人。他们重视协作式建模。他们重视可视化建模工具。他们希望对一个领域有深入的了解。这就是DDD社区的完美工具。
 

误解与常见的问题

软件开发人员和业务部门的人之间的误解，或者你可以称之为业务领域，是一个常见的问题。

我认为这一直是个问题，至少在我的经验中是这样。在软件开发中，人们想出了一些技术，试图解决这个问题，例如，整个敏捷方法。

发明这个方法的原因之一，或者说人们想出了这个方法，或者说这个方法变得如此流行，是因为你想把了解这个领域的人聚集在一起，他们有这个需求，他们将使用这个软件，还有开发这个软件的人，并试图在早期发现这些误解，而不是像这样：这个软件建了两年，他们在这个软件上工作，最后他们发货了，然后用户说，"这不是我想要的东西"。

领域故事和其他可视化建模技术，它们只是帮助缓解这个问题的额外手段，因为你很早就得到了一些东西，让利益相关者、领域专家、未来的用户有机会说，"哦，这不是我的意思。不，不，这不是我想让你建立的东西"。

你可以将这种技术用于不同的目的，但其中一个目的是了解领域的情况。因此，如果你是一个领域的新手，如果你以前没有在这个领域工作过，这是第一个可能出现误解的点，因为你不理解这个领域的概念，人们使用的术语。

当我们对所谓的 "将要发生的过程 "进行建模时，我们也可以避免误解。那么，你想如何使用我们将要建立的那个软件？你打算如何使用它？它将如何改变部门的工作流程？ 

 

了解领域的重要性

要建立一个可用的商业软件，你必须首先了解这个领域。

其中一个很大的好处是，如果你问用户他们想要什么，他们往往不善于阐述一个软件如何帮助他们解决问题，因为他们不是软件开发的专家。他们不知道现代技术的所有手段，而且知道这些也不是他们的工作，因为他们是领域专家。他们不是软件专家。

如果开发人员，如果开发团队对该领域有了解，那是很好的，因为他们可以提出更好的解决方案，而不是仅仅依靠，嗯，这是用户告诉我他们想要的东西，这就是我要建立的东西。但也许还有其他更好的解决方案。

我认为，作为一个软件开发者，你的工作就是要有这些想法，思考我如何能从用户的（角度）以最好的方式解决这个问题。而这不一定是未来用户心中的同一个解决方案。他们往往受限于他们所知道的东西。他们被他们已经习惯使用的现有软件系统所限制。

领域故事

• 这是两件事的结合。
• 一种是象形语言，因此它是一种用于建模业务流程的符号。基本思想是我们有一组简单的图标。
  
  • 我们有“演员角色Actor”，他们是我们软件系统中做事的人，故事围绕着这些演员演进。所以他们是故事中的活跃部分。他们做什么？嗯，他们创造东西，他们使用东西，他们交换东西，那些我们称之为工作对象的东西，所以它们可以是物理的东西，比如纸上的文件。
  • 然后我们有描绘活动的箭头。这个想法是象形语言遵循自然语言。所以你可以大声读出来。故事由不止一个句子组成。
  • 我们如何表达一个序列？其他建模技术，它们从左到右或从上到下建模。但在这里，我们使用数字。所以我们给箭头编号，这让我们有机会更自由地布置故事。
  • 例如，将属于同一子域或发生在同一位置的故事部分组合在一起。所以这给了我们更多的自由来布置故事来表达一些额外的意义。
• 领域故事的第二部分是它也是一种研讨会形式。我有时也会做的是您可以自己使用域讲故事。但通常，这是一项协作活动。
  
  • 这意味着我们有有问题的人和有答案的人，我们将他们聚集在一起。例如，有问题的人是开发团队的成员和有答案的人。他们是各种各样的利益相关者。所以我们有系统的未来用户。我们还有其他利益相关者。我们可能有产品经理或 PO、产品负责人和经理等等。我们将它们放在一个房间里，或者可能在 Zoom 通话中。我们让他们告诉我们有关他们领域的故事。
  • 什么是故事？嗯，这是一个场景，它是一个领域中实际发生的事情的具体例子。因此，我们并不是在谈论业务流程，因为这些都是可能发生的所有可能发生的事情，或者发生这种情况或发生那种情况。他们给我们举了一个具体的例子。
  • 例如，典型案例或最常见的案例，或最简单的案例，或常见的错误场景。我们采用这种情况并从头到尾告诉它，没有任何如果，没有案例。我们只看最重要的例子。也许两三个例子就足以真正理解一个业务流程。
  • 当领域专家讲述故事时，有一个主持人。他或她，他们以视觉方式记录领域故事，这意味着他们创造了象形语言的图片，并且它同时发生。这为我们提供了一个很好的工具来处理这些误解。因此，重要的是每个人都可以看到正在创建的图片。
  • 这种研讨会形式和在那里创建的这种对话，至少与最终图片和最终结果一样重要。因为经常，根据我在研讨会上的经验，这就像一场篝火晚会。如果你看一下完成的图片，那些在车间里的人，他们就知道它是关于什么的。如果您只是将它展示给其他人，那么它与在创建它时在那里是不同的。
• 这就是为什么我通常会说，即使你可以独立使用象形语言和研讨会格式，但如果你结合使用它，你会从中获得最大的好处。

DDD角度

• 您不必使用领域驱动设计来应用此技术。在我们进入这个领域驱动设计社区之前，我们已经应用了几年，它仍然有效。
• 从某种意义上说，它是领域驱动的，它是关于业务、关于领域、关于人、关于人们的任务和活动的。但它不受域驱动设计的这种特殊方法的约束。
• 但是，如果您从事领域驱动设计，您将希望看到它可以帮助您解决该领域的某些活动或某些问题。例如，为有界上下文寻找边界，或开发可实现的域模型。
• 我认为 Domain Storytelling 确实丰富了 DDD 工具箱。但是没有必要为此使用 DDD。
• 事实上，即使没有开发软件的目标，您也可以使用 Domain Storytelling。因此，人们使用它来优化组织中的工作流程，或做出“制定或购买”决策。

当领域专家不可用时

• 如果您查看分析领域的经典目的，那么我认为没有领域专家就行不通。但是，例如，如果您处于初创公司的情况，或者如果我拥有非常技术性的领域，那么您可以与技术专家一起完成。
• 我们在那里所做的是，我正在与对这个新业务领域有这个想法的经理一起工作，他们脑子里有这个商业模式。他们正试图讲述他们拥有的这个新商业理念的故事。所以还没有用户。目前还没有其他领域专家。这只是他们脑海中的一个想法。
• 你能用它来编故事吗？这非常关键。否则，它只是一种商业模式。但是把它带入生活，让它活起来，这是你可以用故事做得很好的事情。

领域故事工具

• 这种象形文字与人们通常知道的其他符号大不相同。它看起来与 UML 活动图或 BPMN 大不相同。所以我建议先练习一下这种象形语言。
• 首先，要充分理解这是如何写下来的，因为这会影响建模会话的速度。一方面，您不希望与很多人进行建模会议，而您是阻碍所有人的人。所以你应该非常流利地使用这种象形语言。
• 当然，更复杂的部分是与人合作。这并不是这种技术独有的问题。当你与一群有不同观点、不同观点的人一起工作时，这是一个普遍的问题。
• 你怎么能为此做好准备？而我通常推荐和我做的是，首先做一个一对一的采访风格的讲故事工作坊。例如，找一个同事，让他们告诉你一个故事，然后你试着想象一下。因为那时你只需要和一个人打交道，通常他们不会不同意自己，所以会容易一些。然后，以此为基础，与更多人一起做。

象形语言

• 领域故事可以在不同的粒度级别上播放。所以我们可以对某事有一个粗粒度的概述，或者有一个细粒度的故事。不同层次的细节——这就是我们所说的故事的“范围”。故事的范围由几个方面组成。所以你有它的粒度。
• 然后我已经谈到的另一个因素是您查看的时间点。您是否以目前的方式看待事物？我们称之为“原样”的流程。所以这更多是使用领域故事的分析方式，分析它们。或者你想设计一些新的东西？一个新流程以及软件如何支持它？然后这是一个在未来上演的“未来”故事。
• 根据他们的目标，您可以选择不同的范围。这也决定了您必须在故事中加入多少细节。
• 如果你稍微细化一点，你会看到软件系统，它们也被建模为演员。因为它们通常在流程中也很活跃。因此，他们为您提供了一些信息。他们计算一些东西。他们生成报告或他们所做的任何事情。因此，对于域故事来说，其中包含少数演员是很典型的。因此，您将拥有使用系统（和系统）本身的人。甚至可能是一些没有直接用户的后台系统。
• 但是当它变得过于技术性时，例如你说的 API，或者在我提到技术协议之前，我通常会切换到其他形式的建模方法。这也是典型的，在一个项目中，我经常结合不同的建模方法，以便我为手头的每一项任务拥有完美的工具。在某种程度上，您仍然可以使用 Domain Storytelling 来做到这一点，但通常，我会将它们推荐给其他一些更适合实际建模软件工作方式的建模方法。

翻译成软件

• 最常见的是，我们首先翻译它，或者我们用它来推导，提出需求。例如，用户故事。它不一定是用户故事。你也可以有一些其他的格式，例如用例。
• 当然，这与领域故事的可视化方式有关，因为那里还有演员。那些是用户。好吧，他们是做什么的？这就是活动箭头的描述。所以很容易翻译。
• 对于涉及业务流程的各种本质上是过程的需求，您可以通过对领域故事建模然后将它们转换为用户故事来非常容易地提出它们。然后，当然，您需要在需求中添加一些细节。
• 从领域故事中，我们得出粗粒度的需求，然后您将继续在其中投入更多的工作，并提出验收标准之类的东西。从那里开始，您将进入软件开发领域。

与事件风暴的区别

• 我通常说 Event Storming、Domain Storytelling，还有其他技术，如用户故事映射或示例映射，它们都像家庭成员。所以他们都是这个协同建模方法家族的成员，这意味着他们有一些共同点。但是，他们也有一些领域，其中一个比另一个更适合。
• 当然，建模语言有点不同，因为它们有这些便笺并且它们是彩色编码的。演示文稿中最重要的元素是领域中发生的事件或事情。您将业务流程表达为从左到右的一系列事件，这就是您的时间线。这已经是很大的不同了。
• 如果它是一个涉及很多人的问题、领域或业务流程，并且会进行很多交互。在涉及多个系统之后，了解有关此交互的更多信息是很有意义的。我们想看看谁和谁一起做什么。然后我会选择Domain Storytelling。
• 如果我知道该领域更多地是关于状态变化，更多地是关于这个时间序列，那么事件风暴可能是更好的选择。
• 有时也可以很有趣地询问这个过程已经成熟到什么程度。那么它是人们真正可以谈论的东西吗？然后，再次，我宁愿使用域讲故事。
• 如果他们需要 Event Storming 的这种头脑风暴方面的内容，可以有一个促进者，但它不像 Domain Storytelling 那样严格，所以每个人都只是从在墙上贴上橙色便签开始。因此，如果我的印象是这有助于让他们自由表达他们的想法，那么我宁愿选择 Event Storming。
• 这里有不同的因素在起作用。我经常在同一个项目或同一个车间中使用这两种技术。

在线协作研讨会

• 令我惊讶的是，这非常有效。我从事在线协作建模已经将近两年了。我无法想象它会运作得这么好。但是，您仍然需要注意一些事情。这个由协作建模从业者组成的整个社区，他们在博客文章和聚会中分享了他们的经验。
• 最重要的方面是您有在线建模工具或一些您可以共享并且每个人都可以看到的建模工具。因此，无论是您使用的虚拟白板还是其他建模工具，版主都会分享，每个人都可以看到和互动。
• 特别是对于较大的团体，拥有第二个促进者或主持人真的很有好处。因为在 Zoom 通话中、在虚拟会议中关注人员比在现实生活中的会议中更具挑战性。如果你们都在一个房间里，肢体语言很容易丢失，有时人们会关掉摄像头，那么你就失去了获取反馈的途径。
• 一个小技巧是，例如，另一个人跟踪人们的活跃程度。所以只是一个人还没有说什么，那么我们可以主动征求这个人的意见，比如。
• 我认为协作建模最重要的工具是每个人都可以看到模型。因此，您将不得不使用一些软件工具进行建模。经典的白板或墙上的造型对于这个来说是不可能的。
• 当谈到域故事讲述时，我们为此构建了自己的小型开源工具。我们构建的工具称为 Egon.io。它是开源的。我认为主要优点之一是它可以重播故事。所以这实际上是我建造它的原因之一。
• 如果你只使用一些通用的绘图工具，绘图与建模是不一样的。所以绘图工具不知道符号和语法。