经验分享：在金融企业中实施领域驱动设计的敏捷实践 | 敏捷联盟

我参与了几次敏捷转换。我所工作的每家公司都提出了同样的问题：我们如何将当前的软件划分为团队，以及我们如何使这些团队与我们的业务目标保持一致？在本报告中，我将分享我的经验，帮助公司使用领域驱动设计方法向敏捷自治团队迈进。

1.引言

我的名字是Kenny Baas-Schwegler。我是一家名为Xebia的荷兰咨询公司的战略软件交付顾问。我将工作重点放在软件架构以及我们如何在一个称为“社会技术架构”的混淆中设计团队和软件，并将这些与业务目标高度一致。我通过促进视觉会议来做到这一点。我在混乱中茁壮成长，但我专注于开发结构化软件。

多年来，我参与了几次转型，从DevOps到Digital再到Agile。这些转变通常侧重于将人员转变为不超过8人的近自治团队，他们将以敏捷的方式工作。我所工作的每家公司都在这些转变中提出了同样的问题：我们如何在团队之间划分当前的软件，以及我们如何使这些团队与我们的业务架构保持一致？

为解决这些问题，公司请求我帮助 使用领域驱动设计（DDD）方法设计微服务 。这种方法使得基于已识别的边界（称为“有界上下文”）更容易在团队之间分发软件。

虽然我认为参与敏捷转换的企业至少需要一种域驱动设计方法来创建具有松散耦合的自主对齐团队架构，这个过程提出了独特的挑战。在这份经验报告中，我分享了使用DDD将金融企业转变为敏捷自治团队六个月的经验。我还更广泛地讨论了我认为最有效的DDD实践。

2.背景

我对结构化软件和架构的关注可能源于我在嵌入式电子工程方面的背景，其中设计精良的印刷电路板至关重要。凭借我幼稚的学生头脑，我成为大型金融公司的软件工程师，并对软件设计过程过于复杂感到震惊！

观察这个烂摊子，我开始寻找为什么会出现这种情况的答案，并找到了一本由Eric Evans撰写的大蓝皮书，名为“ 领域驱动设计：解决软件中心的复杂性”（2003）。我发现这本书很有挑战性，因为这不是你在一周内阅读的内容。

我在工作中苦苦挣扎，因为我工作的公司也做了敏捷过渡，需要在一半的时间内完成两倍的工作。该团队正在努力将自己划分为敏捷团队。尽管有大量的知识共享，但单体软件应用程序很难切分开。我们从一个团队的14人开始。虽然我们开始使用的敏捷框架Scrum已经帮助我们管理了我们的工作，但我们当然没有在一半的时间内完成两倍的工作。我的直觉告诉我，DDD会帮助我们分成更多的自治团队。但由于DDD对我来说太新了，我无法将这个想法卖给管理层。

对我来说幸运的是，应用程序重新设计使其成为我们的待办事项，这是尝试DDD的最佳时机。我们能够划分该应用程序并降低与现有环境的耦合。我们从两位开发人员和产品所有者开始。在几个冲刺中，我们能够安全地进入生产而不会损害当前的应用程序。这对团队来说非常成功，因为我们现在可以在内部应用DDD研讨会。我们也知道我们现在能够使用DDD来处理软件架构。

五年后，我发现我不是因为使用新技术而是来自解决复杂领域而感到高兴。因此，我离开了我的第一家公司并成为了一名顾问，以进一步提高我在复杂领域的软件架构方面的技能。本报告将描述我在咨询过的公司中目睹的几种模式，重点介绍我在Lowlanders的经历。

Lowlanders是一家销售灵活抵押贷款的重要金融公司的一部分。业务和IT是组织结构图上的独立部门。在我加入之前，他们有一个遗留的单片“大泥球”应用程序景观，这在大型金融公司中很常见。他们已经开始进行敏捷转型，IT部门正在彻底改革他们的IT环境，将微服务作为解决方案来解开他们的“企业意大利面条”。

IT部门经理聘请我咨询DDD。我需要帮助解开他们的系统环境并将其转换为自主团队，他们将在新技术堆栈上构建微服务。

什么是领域驱动设计？

领域驱动设计是软件开发的整体方法。Eric Evans在他2003年的书中创造了DDD，解决了软件团队在自主构建软件方面遇到的困难。多个团队设计和构建复杂的解决方案作为单片软件，通常只使用一个模型来解决许多不同的问题。他还讨论了业务所使用的语言与模型中的语言之间的模糊性，从而导致团队内部和团队之间的混淆和纠缠。

这种模糊性的一个很好的例子是公司对客户的看法。公司通常只从一个角度考虑客户，但实际上客户有多种不同的背景。例如，在荷兰，客户通常可以每年注册一次新的健康保险。为此，客户必须在新年开始之前取消旧保险，并在一年的前两个月内购买新保险。大多数荷兰人在新的一年前一到两个月转换保险公司以保证安全。在这一年的最后两个月，如果健康保险公司只在一年中的其他时间看待客户，那么它们就是有限的。虽然已转换为公司政策的客户尚未成为保险客户，但他们可能会遇到需要解决的问题。在这种情况下，公司需要将其视为有资格获得客户支持的客户。在这个例子中，我们看到很多歧义和许多例外。

为了解决这个问题，Eric创建了有界上下文的概念，这是一种基于一致语言模型划分软件的模式。在有界的上下文中，我们通过业务专家和软件人员之间的对话创建共享语言。这成为无处不在的语言。我们专注于一种简洁描述领域内情况的语言。我们创建了几个有界的上下文，而不是一个规范的语言，每个上下文都有自己特定的语言和模型。

在有界的上下文中，当团队成员开发软件时，一个团队可以获得其模型的所有权并增加其自主权。他们可以单独测试，因为团队可以清楚地了解他们的客户是谁，并且可以接收他们自己的反馈指标。Nicole Forsgren博士，Jez Humble和Gene Kim（2018）的研究表明， 持续交付绩效和成功组织扩展的最强预测因素是松散耦合的团队 ，这些团队通过松散耦合的软件架构实现。如果你想要加速，这使得有界上下文成为一个非常重要的模式！

领域知识 - 问题空间

虽然使用有界上下文在DDD中划分模型可以提高自主权，但我并不相信团队的完全自主权。系统和团队之间总会有耦合。只有通过设计清晰的界限，并通过决定事物在界限之间移动的位置和方式，我们才能创造自主权。使用有界上下文模式，我们可以降低团队之间的耦合，并为每个团队提供独特的目的。

定义明确边界的第一步是获得领域的知识。我在与Lowlanders合作的早期就​​发现了这一点。我的第一次会议涉及几个业务利益相关者，产品所有者和许多开发人员。产品所有者和业务利益相关者都拥有大量的领域知识，这感觉很棒，因为我知道至少在房间里有合适的人。

在两个小时的会议之后，所有开发人员对结果感到非常兴奋，他们说：“我们终于可以更深入地了解我们需要构建的软件。”然而，利益相关者和产品所有者并不那么开心。在一次私人谈话中，他们告诉我，“我们已经知道所讨论的一切。”

在与开发人员交谈时，我还了解到他们每个人都使用不同的业务描述，并对业务领域有不同的看法。

这个例子表明，如果团队缺乏对域的了解或对域有不同的理解，那么为企业设计有界的上下文是很困难的。如果缺乏这种知识，IT团队将无法构建合适的软件，业务，最终客户将无法获得他们真正需要的东西。

因此，为了对我们的领域有一个共同的理解，我们必须首先深入了解我们在DDD中所谓的“问题空间”.Mathias Verraes将问题空间解释为“我们认识它的世界。”这是问题、模型和业务架构。作为软件工程师，我们必须充分了解问题空间以构建正确的解决方案，而同时作为为这些问题开发解决方案的软件工程师，我们必须亲自了解问题的知识。更重要的是，我们必须继续了解问题空间。虽然问题空间通常是稳定的，但是当我们获得新的见解时它会发生变化。

这些见解可以来自业务方面或来自软件工程师。这是一项集体努力，这一事实构成了领域驱动设计中的最大问题 。在大多数企业中，软件团队被视为工厂。您为团队提供功能性设计，他们将提供软件。事实并非如此，因为正如Alberto Brandolini所引用的那样：“不是领域专家知识进入了生产中软件，而是开发人员自己的见解。”（banq注：盲人摸象）

协作建模的集体知识

我们可以从业务架构中掌握很多领域知识。在过去，我发现即使公司有业务架构，它通常也会过时或与公司的集体看法不一致。这是文档的整体问题。文档确实在知识获取中至关重要，但是没有记录为什么做出这些写在文档上的决策的历史知识，我们很难创建当前架构的文档历史轨迹并使其保持最新；如果你使用图表和可视化形式的文档，这些还是需要创建它们的人的解释，以便其他人获得见解。

不幸的是，Lowlanders没有业务架构，所以我们需要建立一个。最好的方法是收集公司内部的集体知识。

此过程需要面对面的协作建模。要进行协作建模，我们必须邀请集体了解整个业务线的合适人员参加六到八小时的会议。在我在洛朗德任职的开始时，很难找到这些人的名单，而且当他们全部可用时，几乎不可能找到一个四到六个小时的时间段。因此，我依靠IT经理告诉我合适的人是谁，并找到一个“最佳点”：他应该是可以获得最多知识最多的人。

发送邀请也带来了挑战，我们如何向本来就没有多少空闲时间的重要业务利益相关者邀请参加这样的研讨会？政治化和良好的营销在这里派上用场。如果我能弄清楚他们的痛苦并将其与参加本次研讨会的好处联系起来，他们就会更愿意来。在Lowlanders，我联系了利益相关者并进行了公开访谈，这样就能让他们明白研讨会会解决他们的痛点。

当我有足够的信息时，我确定了合适的时间并邀请所有人。我确保拥有最多知识的基本人才能来。我还想让会议对所有相关人员开放。我总是想要包括人，因为他们拥有的洞察力越多，他们的业务和软件就越好。但是，我确实需要管理邀请的数量。我只有两位同事来帮助这个研讨会，我只能亲自为30位积极贡献的人提供帮助。

使用EventStorming进行可视化会议

一旦我们让每个人都在同一个房间里拥有正确的知识，我们就可以进行协作建模了。为了从协作建模会话中获得最多的领域知识，我们需要以与传统会议的方式不同的方式开展会议。你可能对这些传统会议非常熟悉，我们坐在桌子旁讨论事情。

学习很复杂，没有一种统一的学习方法。然而，大脑科学展示了我们如何更有效地学习。我发现Sharon Bowman在她的在线文章“六张王炸six Trumps ：制造训练棒的大脑科学”中讨论的"六张王炸"特别有用：

1. 运动胜过坐着。
2. 说话胜过听力。
3. 图像胜过言语。
4. 写作胜过阅读。
5. 更短胜过更长。
6. 不同胜过相同。

公司低估了这些王炸的力量。根据我的经验，大白板，大量处理便签的空间，以及要求人们在视觉上分享知识可以大大增加知识共享。

但是我们不能把胶粘物直接扔在墙上并期望它能够起作用，而且我们不能使用需要大量时间和认证来学习的新技术。我们想要足够的结构来开始分享。

我最喜欢的工具之一是由Alberto Brandolini开发的EventStorming事件风暴。自从Mathias Verraes五年前在为期三天的DDD研讨会上向我展示以来，我一直在使用EventStorming。这个用于探索和学习复杂领域的工具的力量让我感到惊讶。

对于不同类型的工作室，我可能已经使用了200多次。我甚至用它作为计划我最近婚礼的工具，取得了巨大的成功！

EventStorming是一种灵活的研讨会格式，用于协作探索复杂的业务领域。您可以直接进入并快速轻松地学习它。它具有不同的格式，允许您分享全局视觉和知识，并了解特定流程并直接进入解决方案领域。

设置很简单。它涉及找到足够大的墙来挂纸，邀请合适的人（有知识的人和那些实施知识的人），并给每个人提供相同的特殊颜色的粘滞便笺（最好是橙色）和笔。

会议间环境非常重要，需要足够的墙面空间，新鲜空气和巧克力等零食。没有什么比缺氧或糖更能杀死一个30人的工作室了！

你也希望人们保持活跃，因此太多椅子可能是个问题。我通常会包括几把椅子，所以我可以看到人们不知所措，需要休息一下。一旦人们坐下来，他们可能需要休息，我会尝试与小组确认。

这不只是关于IT的

为了获得对整个域的共同理解并开始设计有界的上下文以转向自主对齐团队，我使用了一种名为“Big Picture”的特定EventStorming格式。我在Lowlanders的Big Picture EventStorming会话中的第一步是要求参与者开始写入领域事件。领域事件相对易于理解。就是已经发生或可能发生的事情，这对于业务来说非常重要。Lowlanders的例子包括：

• 已收到抵押贷款请求
• 抵押贷款申请通过
• 招标签字
• 申请遭拒绝

我告诉参与者我们不想包含任何技术事件 - 没有数据库连接，没有应用程序名称，当然也没有Excel。我们只想使用与业务相关的语言。

但是，我不会在一开始就强制执行这些规则，因为我宁愿让他们在纸上得到他们的第一个想法。我要求他们不要过多考虑他们如何写东西，只是为了写出想到的东西。对每个人来说，分享他们的感知是最重要的，而且在粘滞便笺上写的东西比生产代码更容易被重构和重写。我通过将粘性物质破碎并将其扔在棕色纸前面的地面上来证明这一点并告诉他们“一个好的会议将在地面上有很多这些粘性物质。”

参与者在一个粘性便签上写了他们熟悉的领域事件。我让他们自己这样做，这样他们就可以记录自己的观点。我不能强调这个过程由多么重要性。我们希望人们将他们的观点置于我称之为“共享的理解池”（例如墙上的棕色纸）上。这些观点引出了我们希望清楚看到的语言分歧和误解。

我告诉人们会有混乱，但我们最终会为它带来秩序。虽然有些人开始担心，但当我告诉他们时，我会大笑起来。我发现许多人一开始就不能轻易处理这个非结构化的议程，这就是为什么我告诉别人一切都会好起来的重要。

起初，人们对写下什么有很多疑问。例如，他们询问某个事件是否在范围内，并想知道他们可以写哪些。我不回答这些问题，因为我的回答可能会影响他们的编写。然而，我注意到有些人根本不会开始写，因为他们似乎迷失了。这对我作为推动者来说是一种压力。如何解除不写的人，不要过多地用偏见对待他们！

我会展示在其他域共享的示例并向他们展示领域事件是什么，但我没有明确告诉他们要写什么。我与某些参与者进行了一些非常尴尬的互动，我可以感受到他们的焦虑，并感觉到他们陷入了精神障碍。

一旦每个人都在忙着写他们的领域活动事件并且房间很安静，我通常会感到更加紧张。人们完全沉默，我处于不确定状态。这很正常，但对我来说也不舒服。我现在有时间思考并担心我的任务的成功将在接下来的15-20分钟内决定。

我最担心的是人们会毫不犹豫地写下他们所知道的一切。在这个过程中，让人们对他们的知识保持透明是很重要的。不幸的是，企业文化往往不鼓励这种透明度，企业文化通常是病态的权力导向或官僚式的规则导向。成功的知识共享和领域发现要求允许人们犯错。为了培养这种开放性和脆弱性，我使用了两个辅导员，一个主动参与研讨会的人和一个观察的被动者。观察者可以获取信息共享可能遗漏的大量有价值的信息。相当多的知识存在于文化和人们互相交流的方式中。

一旦人们准备好了，他们就可以开始要将便签放在墙上。从左到右的时间顺序，我请他们根据他们的观点在这个时间表上贴上便签。这一部分需要促进，因为我们正在进入混乱和困难地方。期望被管理再次变得至关重要。我想让事情自发地发生，但我也需要管理因混乱而陷入困境的人。我减轻混乱的一种方法是总是有一个事件挂图，我写下符号的图例，如果需要的话，还有一个议程。

执行时间表

一旦每个人都写了他们的领域事件，就该着手解决混乱了。我要求参与者从“强制执行时间表”开始。这意味着以他们认为最合适的方式协作构建和合并时间轴事件。我要求他们将两个胶粘物彼此靠近，并决定哪一个先出现。在有30人的Lowlanders研讨会上，一些群体很明显对特定事件有强烈的感受。当这种情况发生时，这些群体创造了自然知识边界和不同需求的边界。这些观察结果提供了有助于以后设计有界上下文的见解。

为了进一步构建EventStorm，我介绍了关键事件的概念。关键事件是对业务最重要的特定事件。它们是追随它们的一切的先决条件。房间里的人们共同决定一个关键事件是什么。

一旦我们选择了这些关键事件，我们就会开始寻找其中的具体流程。通常，泳道开始出现，对应于特定团队拥有的业务流程的一部分。然后，我们开始争论关键事件和业务流程的这些部分之间的关​​系。

我们还确定并消除双重事件。如果两个事件看起来是相同的，我会请其中一位作者解释事件的含义。由于语言可能不明确，因此一个领域概念可以使用相同的语言作为完全不同的域概念。例如，Lowlanders以不同的方式使用“pieces”一词。他们的客户需要提供“pieces”以证明他们的抵押贷款要求的工资。在另一个背景下，“pieces”一词描述了抵押贷款的所有组成部分。还称抵押请求中的“pieces”是“举证责任”。正如您可以想象的那样，这种模糊性导致了很多混乱，特别是当我们假设一个术语指的是某个概念时它实际上是完全不同的东西。

因此，您可能想知道我们是否需要规范数据模型。但是，在整个业务范围内使语言保持一致是不可能的。任何人类学家都会告诉你，语言是流动的，受人们的一时兴起。语言应该如此发展。由于语言会发生变化以适应新用户，因此老用户会反对并抱怨。而不是创建一个大的规范语言，最好用一致的语言制作更小，更统一的有界上下文。模糊性是微妙的，它无处不在，Big Picture EventStorming揭示了这种模糊性，让我们定义可能的边界。

关注事件如何发生以及由谁发生

我遵循指导性启发式，这表明我们抵制诱惑，不是弄清楚事件发生的原因，而是关注它们是如何发生的。这在EventStorming的早期阶段中最重要，在它更加一致和完整之前。当小组围绕特定事件形成时，我会关注人们的谈话方式，并提出开放式问题。

很多人开始准确地解释他们做了什么，并远离纸上的事件。然后，我需要提高我的促进技巧，使谈话具体化。每当他们解释他们如何做某事时，我都要求他们指出一个特定的事件。我还要求他们告诉我谁 - 什么角色 - 在这个过程中创建这些事件。我在这里使用一个小粘贴将该角色添加到事件中作为其中那一部分。

了解EventStorming是否完整的一个很好的方法是在纸上出现人们感到高兴的结构。在这一点上，我让他们创建了整个EventStorm的叙述。我要求一名志愿者一步一步地走过每个人的事件流程。在Lowlanders，产品所有者自愿这样做。如果没有志愿者，我通常会自己做。

在Lowlanders会议上，公司的整体商业模式的愿景已经开始出现。此时，更多的讨论和分歧开始发生。说明这些分歧的有效方法是在纸张上与这些参数对应的位置放置一个鲜红色或粉红色的粘滞便笺。如果出现对业务流程的任何其他限制，我们也希望用这样的便签来可视化这些。Lowlanders的这些限制的例子包括：

• 人们仍然需要进行人工审核，这需要花费大量时间。
• 我们已经掌握了客户信息，但我们会将其填入。这不是客户友好的。
• 我们需要与另一个团队来回沟通。 

当你开始完整的叙述时，会发生许多有趣的事情，我们需要密切关注出现的对话。在Lowlanders，产品所有者开始讨论泳道的一部分，另一个产品所有者开始不同意。他们对此进行了简短的讨论，然后产品所有者希望继续前进而不做任何改动或达成协议。我们经常在Lowlanders观察到这种模式，参与者试图避免冲突。但是，我们不能没有冲突地成长，因为我们都对真理有不同的看法。为了真正了解发生的事情，我介入并询问是否每个人都可以达成协议。我们需要确定论证是否已经明确地解决，或者是否应该将其标记为约束。他们同意他们当时无法解决分歧，

绘制系统，约束和机会

一旦我们在EventStorm中捕获了整个业务线，我们就可以开始将系统映射到它上面了。映射系统可以很好地概述当前的应用程序格局以及它与业务的匹配方式。在我们完成研讨会之前，我让参与者写下我没有提出的限制，我也让他们增加了重新思考机会。

重要的是，人们花时间阅读这些新增内容，并且每个人都有机会在没有其他人插话的情况下谈论这些内容两分钟。这创造了对彼此的挑战和关注的共同理解。

在一天结束后我们完成了研讨会，并要求每个人投票给他们认为最有助于整个业务的约束或规则 （banq注：发现隐藏背后的业务规则）。

我们给每个人两个箭头放在墙上，表明他们的选票。得票最多的人成为“约束理论”，这是需要解决的瓶颈。

EventStorm导致对业务的共同理解，业务流程中出现约束的情况以及新兴边界。将完成的纸张留在墙上作为EventStorm的快照非常有用。这允许参与者向其他人解释结果。我们希望保持原样并且在研讨会结束后不做任何改变。虽然我觉得把它留在墙上是最有效的，并且有人在那里向那些不在那里的人解释它，我们也可以录制一个解释叙述的人的视频。如果需要，我们可以提取这些知识来更新我们当前的文档。

架构设计和设计有界的上下文

“架构设计是系统设计。系统设计是上下文设计 - 它本质上是关于边界以及权衡。“ - Ruth Malan

经过培训的领域驱动设计师可以开始在大图中可视化紧急的有界上下文。我们将这些称为“紧急”，因为从全局概述来看，我们仍然不足为这些有界上下文提供严谨性。Lowlanders的问题在于人们没有接受过训练来形象化紧急的有界上下文。因此，他们需要一些这种可视化的帮助。他们的领域专家还需要分享正式的研讨会成果。因此，我开始使用紧急有界上下文设计上下文映射。为此，我们可以使用几种启发式方法：

• 关键事件形成了硬边界和关系。
• 泳道是潜在的有界上下文。
• 不同的角色是潜在的边界。
• 领域专家的专业领域是潜在的边界。
• 需求冲突是潜在的边界。
• 语言的动词表达是不同的。

基于这些启发式方法，我开始在我的白板书上绘制一张背景图，并最终将其绘制在我的平板电脑上。

在与Lowlanders和其他人一起做这件事的时候，我注意到这个可视化虽然是一个快照，但它是对房间里人们的集体感知，并为谈话提供了良好的基础。这种对话可以导致决定向前推进有界上下文的设计并进入解决方案空间。

解决方案空间

Mathias Verraes将解决方案空间描述为“我们设计它时的解决方案（并受到您提到的力量的限制）。”

这是我们用软件架构来管理复杂性的空间，也是我们故意设计一种无处不在的普遍使用的语言的地方，Rebecca Wirfs-Brock对解决模型进行了很好的解释：“模型是对事物或现象的简化表示，故意强调某些方面而忽略其他方面。具体使用的抽象记在心里。除非你故意遗漏或过分强调误导，否则没有错。“

设计软件团队并与业务保持一致 - 社会技术架构

在Lowlanders，我们现在采用紧急的有界上下文，邀请可能在该领域（和其他相关人员）中实施软件的团队，并启动另一个协作建模会话。

这一次，我们使用流程Process和Software EventStorming来清楚地定义我们的有界上下文并设计一个解决问题的潜在模型。我们可能会使用其他技术（如示例映射，影响映射或用户故事映射）来开始更多可视化。

在场的团队可以决定哪个团队将开始研究哪些有界上下文，他们将如何与业务保持一致，以及他们将使用哪些战略模式。当然，由具有经验和知识的架构师执教。

设计所有团队成员的软件可以创建共享理解和共享所有权。我们希望设计高度符合商业价值的团队和软件，我们称之为“社会技术架构”，以确保我们从商业理念到生产的交换最少，创建自主协调的团队。

结论

领域驱动设计和大图片EventStorming是分享知识和创建整个业务线共享愿景的强大工具。在这个共同愿景中，我们还可以共同确定对我们业务战略的最重要限制。单独改进系统的每个部分永远不会产生与整个系统相同的结果。我们希望在最重要的地方改进我们的工作，在他们对提高绩效产生最大影响的领域。大图片EventStorming会议是可视化此变化的绝佳机会。

我在Lowlanders观察到的是，如果业务没有分配时间，IT团队就无法采取行动，也不想做任何事情。例如，工程师团队并不总是有时间学习构建正确事物所需的领域知识。团队很高兴参加EventStorming会议以增加他们的领域知识，但产品所有者抱怨说，“我已经知道所有这些，而且需要花费很多时间。”

在与产品所有者讨论之后，我可以理解他们的观点。他们的管理层也有同样的情况。他们有目标，他们需要确定性。因此，如果我们想要开始创建更好的软件，那么业务和IT之间的一致性就至关重要。

为了实现一致性，我们需要停止在业务和IT方面进行思考，并开始作为一个整合的团队。

EventStorming通过打破业务和IT之间的障碍来帮助我们实现这一目标。它使我们能够分享有关我们的工作，我们为什么这样做以及我们如何做的知识。通过设计有界的上下文，我们可以确保单个团队拥有独立开发和发布符合业务目标的软件所需的自主权。这并不容易，但在我看来，这是建立优质软件和与更快的鱼一起游泳的唯一方法！