DDD事件风暴的详细议程

19-01-18 banq
                   

刚开始在一个项目中使用DDD Big Picture Event Storming可能会很混乱,这里描述一个详细的议程和一个案例简报,保证其在正确的轨道上实行。

每次我参加DDD的Big Picture Event Storming研讨会时,我得到的主要反馈是“这是一次大规模的学习!”。让所需人员在一起几个小时会触发重要的对话。

这就是为什么Big Picture Event Storming非常适合启动新项目的原因。一旦每个人都对问题域了解得足够多,他们就能更好地协同工作 他们可以讨论架构,并起草目标愿景。他们还可以集体讨论团队组织。对于现有系统,他们可以比较不同的迁移策略。例如,重写或重构是否更好?

一旦每个人都对问题域了解得足够多,他们就能更好地协同工作。

更糟糕的是,并非全部。在探索域空间时可能会发生两件事。他们会发现现有的问题。他们还将就领域名某个特定的定义达成一致。这些都是快速获胜的结果。

奇妙的是我们可以在很短的时间内完成所有这些!这是DDD事件风暴的真正力量。在几天之内,我们可以让每个人走上可持续发展的道路,从而实现共同的,足够好的愿景!

在此之前,准备是成功的关键

支持赞助​​​​​​​

最重要的事情就是找到好的赞助。通过良好的支持赞助,我的意思是有影响力的人的支持。你想要的是你的工作室成为团队的主动权,而不仅仅是你的主动性。

与这些人进行私人聊天是赢得胜利的最佳方式。最后,您希望他们共享并支持Event Storming会话的共同目标。

范围

有了明确的目标,您应该大致了解会话的范围。DDD Event Storming是一种探索性(而且相当混乱)的活动。不习惯的人一开始会感到有些失落。为了解决这个问题,我发现最好围绕1或2个用例启动研讨会。因此,请与您的赞助商或其他领域专家聊聊,预先提出这些用例。

正如我所说,Eve​​nt Storming本质上是探索性的。有关这些用例的讨论将在会议期间引起其他问题。由小组决定是否在范围内添加它们。从精确和具体的用例开始是可以的,没有必要害怕错过的东西。

识别第一个领域事件也是一个好主意。它既可以作为一个例子,也可以作为触发事件风暴的一种方式。根据经验,这个事件应该在故事的中间。它也应该足够清楚,让每个人都能理解。例子:

  • 交易被预订了
  • 订单被支付了

如果您想知道领域活动是什么,请不要担心,我稍后会详细介绍。

听众

现在是列出理想受众的时候了。我发现50%的领域专家和50%的技术人员会话会议效果更好。

由于会议室专家太少,研讨会成为单向教学课程。理想情况下,我们将为您在研讨会范围内预见的所有功能区域提供专家。

我们还需要在研讨会上有相当多的技术人员。最后,这是我们想要发展的领域知识。

请帖

到目前为止,你有了赞助商,一个明确的目标,一些初始用例和理想的受众。接下来要做的就是发送诱人的邀请。这取决于组织,需要或多或少的努力才能让人们参加。

确保在邀请中可以看到赞助商以最大限度地获得支持。例如,请一位有影响力的赞助商为您发送邀请。 

简报

当您有最终的与会者名单时,请向他们简要介绍研讨会的目标。这有助于人们在很多方面:

  • 要明白这个目标值得他们的时间
  • 为最初的迷失方向做好准备
  • 了解会话将如何进行
  • 获得快速问题的答案

我发现快速的15到30分钟的聚会很有效,但同样,您可能需要适应您的组织。用于书面沟通的群组可能更喜欢电子邮件,聊天或维基。重要的是人们可以提出公共问题并获得答案。

视觉议程

我认为在会议开始前准备有用的一件事是视觉议程。正如我所解释的那样,DDD Event Storming第一次会非常令人不安,人们可能会觉得有点迷茫。在会议开始之前,将不同颜色的便签粘贴在房间的其他墙壁上。与视觉议程一起走过不同步骤的与会者将使他们放心。这也是突出事件风暴的一些规则的好方法。

无限的设计空间

到目前为止,最奇特和最困难的事情是有足够大的墙来做研讨会。Event Storming的发明者Alberto Brandolini建议使用8米长的墙。有2个目标:

  • 因空间而不受我们设计的限制
  • 有足够的空间让每个人都四处走动和合作

如果你有足够大的房间,这应该是你的第一选择。阿尔贝托说,走廊也是很好的候选人。我对此的经验并不是很成功。当我们尝试它时,参与者抱怨其他人一直来来往往。

一旦你有了房间,你需要一个大的纸卷来粘贴它。这样,您就可以移动您的设计空间。如果您需要延长它,或者如果您决定在工作场所坚持几天,那么您将是安全的。

即时贴

事件风暴消耗了大量便签,特别是领域事件。总而言之,您需要:

  • 许多橙色贴在它上面,每人约一堆
  • 粉红色
  • 大黄色
  • 小黄色
  • 蓝色

水笔

人们需要在帖子上写一些东西。尖锐或小标记是最好的。它们可以从几米读取,但仍然可以让你在一个帖子上写足够的单词。

没有椅子,没有桌子​​​​​​​

典型的会议很无聊,让人昏昏欲睡。相比之下,一个成功的事件风暴研讨会让人们充满活力和富有成效。拆除该区域的椅子和会议桌可以帮助人们保持活力。我们也不希望DDD Event Storming成为一个长期的酷刑会议。因此,我们需要安排足够的休息时间。

在研讨会之前完成了所有准备工作。让我们进入真实的事物。现在我们已准备好一切,我们如何实际开展这个研讨会?

1.准备

  • 拆除桌椅
  • 将设计空间贴在墙上
  • 将视觉议程贴在墙上
  • 在某处放下剩下的材料

2.兴奋剂

正如我已经说过的,DDD Event Storming是一种不同类型的架构会议。如果人们没有摆脱他们的传统方式,这将无法奏效。

提高能量水平也非常有用。事件风暴可能非常紧张和累人,所以他们需要所有能量。您可以在funretrospectives.com找到许多强大的物理能量。我和他们中的很多人都取得了成功。

3.简报和议程

现在是时候介绍研讨会了。从目标,范围和用例开始。这是解释我们将要经历的每一步的好时机,以及它们将如何帮助我们实现最终目标。这也是介绍一些一般惯例的好时机。这是我能说的典型简报。

总目标:

请记住,DDD Event Storming是一种将Big Design Up Front缩短几天的方法!它会很激烈,但我们会在很短的时间内做很多事情。

事件风暴可能是混乱的。它可能很崎岖,有时会以意想不到的方式进行,我们可能需要调整。在一天结束时,成功取决于你想要多少!

目标:

本次研讨会的主要成果是领域专家和开发人员之间的共享知识。我们稍后将以此共享知识为基础。

如果我们想要保持这种合作,我们必须坚持使用领域语言。我见过Event Storming会议中进行技术讨论,而不是进行业务领域讨论。

作用域和用例:

今天,我们将在< 您的作用域 > 的范围内工作。为了使事情更具体一点,我们将从这些用例开始< 列出您的用例 >。我们将围绕域事件进行建模,例如< 您的第一个事件 >。

领域事件:

关于便利贴的简要介绍。

橙色便签用于领域事件。以下是< You sample event >的示例。以下几点可帮助您了解哪些域事件:

  • 你可以在DDD书籍中了解它们
  • 领域专家了解他们
  • 用过去时态写出它们是创造有意义事件的一个技巧。它们不是某人或某事的行为(不是“交易者预订交易”)。即使某些事件是由行动引起的,我们对行动也不感兴趣。
  • 它们不是技术性的,不应该特定于我们系统的实现

领域定义:(又名无处不在的语言

每当我们遇到或在一个领域内达成共识时,请随意在大黄色帖子上为其写一个定义。这是一种构建共享领域词汇表的方法。这对改善我们所有人之间的沟通非常有帮助。这反过来又改善了我们在许多不同方面的工作方式(例如:在选择重构时)。

问题:

同样,我们使用紫色便签来解决“问题”。每当我们遇到:

  • 我们无法回答的问题
  • 一些似乎不对的东西
  • 或者我们应该研究的任何问题

将它记录在紫色的即时贴上。

最后,为了保持步伐可持续发展,我们每50分钟休息5分钟。

4. 领域事件生成

这是研讨会实际开始的时候。要求与会者在用例的上下文中抓住他们可以想到的任何领域事件。为了帮助他们开始,请首先从您事先准备的域事件开始。

在某些时候,你会发现域事件生成的速度会下降。这表明是时候进入下一阶段了。第一阶段通常足够25分钟左右。

5.排序​​​​​​​

在第二阶段,我们将要求他们按时间顺序对事件进行排序。这个想法是代表设计板上的典型工作流程。在生成阶段,人们正在写下他们可以想到的任何事件,这需要他们各自独自工作。在这个阶段,他们需要彼此交谈以对事件进行排序。

这就是DDD Event Storming的神奇之处。与会者都对系统有不同的看法。他们在设计板上实现了一些领域事件。他们需要通过这些差异来讨论事件的排序。

当人们尝试对所有领域事件进行排序时,事件风暴会发挥其魔力。

这一阶段应引发激烈的讨论。希望该小组能够捕获许多领域定义和问题

您可以根据需要随意组织流程表示法:通常情况下,泳道将出现替代品,垂直对齐将表示分支。当发生某种循环时,您可能还会创建重复的即时贴。

6.Actor和外部系统

你已经开始写下你的系统的故事了。所有好故事都有英雄!这一次,请与会者确定触发或响应事件的Actor(有角色的人)。惯例是使用小黄色即时贴。没有必要为每个事件添加一个actor,在一个事件链的开头粘贴一个就足够了。

同样,复杂系统也与外部系统交互。外部系统可以不是操作人员,可以是例如在线API。交互表示是使用蓝色即时贴用于外部系统,将事件放置在与其交互的位置。

(banq注:这两个阶段类似UML的用例图和顺序图阶段)

7.讲故事

现在是时候检查整个画面是否有意义。自人类开始以来,故事一直是知识的载体。过去的知识通过篝火故事代代相传。我们的大脑很难听,记住并理解故事

如果人们害怕单独做这些事情,可以寻找一些志愿者。然后请第一位志愿者讲述系统的故事。他只需要按时间顺序完成事件并解释会发生什么。

正如叙述者所说,观众会提出问题并注意到不一致。这也是添加,删除或替换事件以修复故事的时候了。可能会出现一些额外的定义。如果在会话期间问题看起来太大而无法修复,请将其置于粉红色问题后。

叙述故事可能会非常累人,所以请新的叙述者在某个时候接管。

(banq注:故事注重逻辑顺序)

8.反向讲故事

为了在域中进行更深入的深入研究,可以采用反向讲故事的方式。再找几个志愿者,让他们从最后讲出这个故事。其实是反复询问“可能引发此事件的原因是什么?”。这将生成或更新事件,Actor或外部系统。

这种方法运作良好的原因是问题触发了我们大脑的创造性部分。我们可以想象各种新的可能性。这个阶段非常高效,并带来了很多见解。

9.结束

就是这样,你已经到了DDD Big Picture Event Storming的末尾。在这一点上,安顿下来并评估结果是个好主意。

到目前为止,DDD Big Picture Event Storming的最大成果是对该领域更好的共享理解。

您可能真的想知道可交付成果是什么。此时,大多数可交付成果都是无形资产:

  • 到目前为止,最大的是对领域的更好的共享理解。这将通过改善协作来节省大量时间。它将避免规范错误,并实现更好的设计。
  • 总之,你已经发现了问题。解决这些问题可能是获得高回报的快速胜利。
  • 这些定义是统一语言的第一块砖。利用它可以节省时间并保持系统的概念完整性
  • 最后,这也是协作架构的必要步骤。对领域的良好共享理解使得关于功能架构的讨论成为可能。

因此,接下来的步骤可以是:

  • 解决一个主要问题。Alberto Brandolini在书中回忆起这种情况。实际上,Big Boss已经停止了所有其他工作,直到他们解决了一个“新”问题。
  • 通过添加和改进定义来继续发展无处不在的统一语言
  • 为了起草目标架构,做更多的研讨会。

EventStorming解锁起草架构,绘制团队和可持续的重构路径。

​​​​​​​点击标题见原文系列。

                   

2