“我打开潘多拉的盒子” - 采访DDD事件风暴发明者Alberto Brandolini


Alberto Brandolini是EventStorming的发明者,一种在领域驱动设计环境中的研讨会格式,可让您快速了解软件领域的情况。
Alberto Brandolini是EventStorming方法的发明者 - 这一概念将领域驱动设计(DDD)背后的论文转化为实践。他的书“介绍EventStorming--一种刻意的集体学习行为”总结了他的基本发现。IT咨询公司codecentric的首席顾问兼培训师Tobias Goeschel采访了他。

问:Eric Evans在“领域驱动设计”(2004年)这本书中提出了一种方法,从一个业务部门开始设计复杂的软件系统,首先需要领域专家和软件开发商的合作领域模型。他为应用程序领域设计的讨论提供了设计决策和术语框架。您能否简要解释一下为什么对我们行业中的应用领域的共同理解很重要?

Alberto Brandolini:领域驱动设计揭示了企业软件开发的一个根本缺陷:
假设我们可以根据可靠明确的需求构建软件。
其实这是一种幻觉,也是一种危险的幻觉。
虽然确实存在某些可靠明确的需求,例如:“应该可以从2.1版导入文件”。但是许多需求并非无可争辩,它们包含矛盾, -具有组织中孤岛现象形成的不同的观点和需求,更不用说可能隐藏了个人目标了。Evans也将焦点转移到语言上。即使你可能不能相信,但是确实:语言表达一个概念的术语不是唯一的。
因此,DDD致力于以需要高水平技能和软件架构能力的方式开发软件。这为您提供了多种选择。此外,应该可以开发几种非常有效的模型,每种模型都完全根据当时条件进行定制。
隐形敌人是近年来普遍存在的”大数据中心模式“的概念语言的基本模糊性被以数据为中心的实施所消除,迫使整个公司就”客户“的含义达成一致。或者“订购”意味着以及如何交换数据 - 几年之后发现自己处于僵局:每个人都依赖相同的数据,因此任何变化风险太大,信任丢失,开发速度减慢,工作岗位失去吸引力。

问:但这些并不是新挑战,对吧?
Brandolini:我认为整个问题已经存在了很长时间,但它只是绕着我们的耳朵飞来飞去。两个因素是负责任的。一方面微服务:它们目前已经公布,但它们的承诺只能通过DDD思维方式来实现,特别是在进行有界上下文分析的前提下。其次,劳动力市场:开发商越来越倾向于离开不健康的工作环境,我认为某些架构之间存在强烈的相关性,这些架构害怕破坏某些东西并且无法留住人才。
深入了解域域驱动的域设计可能是更集中的软件开发方法背后的驱动力。应该理解,什么是正确的,并创建最少妥协的软件。它不仅感觉很好,而且还让我想留在公司,所以我可以看到最终会发生什么。

问: 2013年,您展示了您的研讨会概念EventStorming,它将DDD理念转化为团队协作和轻量级建模技术。你是怎么来的?
Brandolini: EventStorming不是一项计划好的发明。在意大利DDD社区的一次小型聚会中,我第一次使用彩色粘滞便笺在一张纸上进行建模。我的朋友Emanuele Delbono主持了研讨会并描述了他想讨论的过程。然后我们分成小组。
我不得不快速放下一些基础知识,所以我拿了一卷纸,开始使用DDD和CQRS(Command Query Responsibility Segregation)构建块来理解我的理解,并在几分钟内完成。与此同时,其他队员甚至还没有开始。
对此重要的是环境:这不是一个业务环境,我在聪明的朋友面前。这种组合给了我最大的实验自由:我可以跳过介绍并直接进入盒子。我们在那里等待交换想法,并立即解决实验中发生的缺点。
然后我开始使用这种方法 - 最初称为基于事件的建模 - 来教授初学者DDD构建块,而不经过传统的定义。真正的突破来自Vaugh Vernon在鲁汶和克拉科夫的IDDD巡演中邀请我作为特邀嘉宾。这不仅仅是一个演讲,它是一个拥有50到70个非常棒的参与者,他们喜欢EventStorming,在他们的工作和当地社区中尝试过它,并提供了非常有价值的反馈,想法和变化。

问:您已经将EventStorming与披萨烘焙进行了比较 - 考虑到需要解决的问题的复杂性,这似乎非常微不足道。
Brandolini:我是意大利人,我知道好披萨的制作真的很复杂。我的一个好朋友是在美食披萨业务,你肯定需要很多知识,从看似简单的成分制作一个令人难忘的产品。
我想用披萨比喻说,合作验证的业务叙事是一个更复杂思维的平台。Big picture配方的变种允许不同的研讨会 - 它们都有相同的基础,但方法可能会有很大不同。
令我兴奋的是,可以将所有参与者的学科中的各个元素组合成一个非常灵活和强大的工具。如果你对食谱采取正统的做法,你就会阻止大部分神奇的创造。当然,有些人会制作糟糕的食谱,但其他人会想出一个很好的食谱。

问:一个房间里有八到十六个参与者经常第一次亲自见面,所有人都有主观观点甚至对应用领域的偏见 - 你如何设法在这些混乱的状态中创造一个连贯的整体画面?
Brandolini:这是适度的任务。没有人愿意成为那个只在墙上粘贴便条并将它们留在混乱的房间里的人。所以我们可以依靠房间里那些有兴趣消除这些烂摊子的人。
更有条理的答案是:一步一步进步。
我们开始混乱地,或者更确切地说,在一个不一致的整体中与零星的统一事件集群。然后我们尝试引入结构。然后我们意识到我们的初始结构是天真的并且应用更复杂的方法,直到我们达到令房间里的每个人都满意的结果。
将混乱清理在一起是学习和团队建设之间的过程。但它也有助于挑战现状:最初的混乱鼓励批评声音,这些声音对那些喜欢从强制的结构开始的人来说,能听进去不那么容易。
连贯性不一定是我的目标。特别是在大局战略层面,我必须想象我们对业务领域的理解的当前状态。如果我们的业务不连贯,我必须现实地描绘它,而不是它的一些光泽版本。所有的分歧都是可视化的,有些可以修复,但不是全部。

问:还有其他方法,如领域故事讲述,主要侧重于在相关各方之间建立同理心。您如何处理讨论的分歧,不同紧迫感和流程的参与者的情感方面?
Brandolini:情绪是情境化的,人们总是对惊喜有好处。希望存在一个决定处理情绪的办法,我认为这是一个坏主意。但作为主持人,我们可以处理这样的系统:一轮混乱的解决问题和机会将给每个人提供机会,有时甚至是匿名,在不公开挑战老板的情况下直观地代表异议。
我看到参与者,那些不参与的人,静静地要求反馈,并遵循肢体语言,看看是否出现问题。我知道一些事情,比如选择一种非正式的语气,以便等级和距离几乎没有空间,我怀疑我也在做一些无意识,让参与者有一种安全感。
但我不得不说整件事情经常会引起一个小小的奇迹:很难惹恼他的同事,尽管他们有局限性,他们显然正在尽力而为。我已经打开潘多拉的盒子 - 但是最后的结果更多的是和解而不是争吵。

问:较大的公司通常有一套独特的规则可以破坏开发人员和领域专家之间的信息自由流动,并使联合研讨会变得困难。你如何处理这样的公司政策?
Brandolini:完全没有。我只能看到它们的效果。通常情况下,我没有被召入组织开始革命。有限制和规定吗?让它可见!让我们看看效果。让我们看看我们的竞争对手是否有同样的问题,或者他们是否有完全相同的限制。一旦它们可见并成为问题的一部分,我们就可以发挥“假设”(banq: 公理法则,第一性原则)。
就个人而言,我发现限制与其最终实施之间经常存在差异。如果限制具有法律背景或限制是基于公司法规,那么总会有一些简单的解决方案以一种示范的方式遵守规则。
解决方案空间中有许多可以使用的可能性:散焦过程可以保持真实的规则精神,而不会陷入僵化的机制。

问:什么问题解决了EventStorming以及如何实现这一目标?什么时候有用?对谁有用?
Brandolini: EventStorming不适合特定问题。它是一个提供可用于更广泛问题的配方的平台。它解决的最明显的问题源于多个孤岛之间的合作,因为缺乏可见性,透明度和共同语言,相互指责很常见。每当需要跨部门边界进行协作时,事件驱动的讲故事和可视化的组合就会非常有用。