设计过程概述 — 用于系统设计的 EventStorming，在需要时提供免费的 UML 图。

在软件开发领域，理解和建模复杂的业务领域仍然是一个持续的挑战。传统上，领域驱动设计 （DDD） 从业者通常从识别领域对象开始，主要关注名词和结构。然而，这种方法可能会导致在完全掌握业务流程的本质之前，对系统架构做出过早的决策。EventStorming 是 Alberto Brandolini 开发的一种创新建模技术，它将焦点从静态结构转移到动态过程。

要了解如何将 EventStorming 用于系统设计的更多信息，请参阅我之前的文章：EventStorming：在域驱动设计中导航复杂域（示例）。

本文探讨了 EventStorming 和领域驱动设计之间的关系，研究了这种以动词为中心的方法如何与 DDD 原则保持一致并与之相辅相成。我们将深入探讨 EventStorming 作为 DDD 框架中的建模语言的优势和局限性，并讨论将其有效集成到设计过程中的策略。

EventStorming 的面向过程的范式

EventStorming 代表了领域建模的范式转变。它不是从领域对象（名词）开始，而是从识别重要的领域事件（动词）开始。这种方法有几个优点：

1. 关注结果：通过强调系统中发生的事情而不是存在的情况，EventStorming 自然而然地与业务流程和用户故事保持一致。
2. 协作建模：该技术规定了与各种利益相关者的参与研讨会，以促进对该领域的共同理解。
3. 叙述流：EventStorming 创建了一种讲故事的领域建模方法，使所有利益相关者更容易访问复杂的领域。

EventStorming 和 DDD：概念映射

为了评估 EventStorming 对领域驱动设计的适用性，我们需要检查其建模概念如何与核心 DDD 战术模式保持一致。以下是映射的细分：

领域驱动设计、战术设计模式和 EvenStorming 概念之间的映射。

直接通信

1. 域事件：在 EventStorm 中由橙色便签表示，这些事件与 DDD 的域事件概念完全一致。
2. 聚合：EventStorming 中的黄色便笺通常对应于 DDD 聚合，但结构细节较少。

隐含概念

1. 实体：虽然不直接表示，但实体通常隐含在事件描述或命令中。
2. 值对象：这些可能是事件或命令详细信息的一部分，但未显式建模。
3. 域服务：通常隐含在复杂的策略或多个聚合之间的交互中。

未直接表示的概念

1. 存储库：隐含在事件的处理和命令的执行中，但未明确建模。
2. 工厂：有时隐含在与创建相关的命令中，但未直接表示。

独特的 EvenstStorming 概念

1. 命令：ften translate to method calls on Aggregates or parameters for Domain Services in DDD.
2. 策略： 可以转换为 DDD 中聚合中的域服务、规范或业务规则。
3. 外部系统： 可能指示 DDD 中需要反腐败层（有界上下文映射）或其他特定集成模式。
4. 读取模型：may translate to Repository，它提供的方法允许客户端请求与某些条件匹配的对象或从对象派生的数据。

DDD 上下文中 EventStorming 的优势

1. 领域探索：EventStorming 擅长揭示领域的动态方面，补充了 DDD 对知识处理的关注。
2. 无处不在的语言：EventStorming 研讨会的协作性质有助于在利益相关者之间开发一种共享语言。
3. 有界上下文识别：事件流通常会自然地揭示域中的边界，从而有助于识别有界上下文。
4. 与事件驱动架构保持一致：EventStorming 自然而然地与 DDD 经常倾向于的架构风格保持一致，例如事件驱动架构、CQRS 和事件溯源。

限制和缓解策略

虽然 EventStorming 提供了许多优点，但它在全面的 DDD 建模环境中也有一些限制：

1. 缺少结构细节：EventStorming 没有提供有关聚合、实体和值对象的内部结构的很多详细信息。
   缓解措施：在需要时使用 UML 图或其他便笺类型补充 EventStorming 以获取结构信息。
2. 某些 DDD 概念的隐式表示：存储库、工厂和某些域服务仅在 EventStorming 中隐含。
   缓解措施：当这些概念对域模型至关重要时，使用互补建模技术明确捕获这些概念。
3. 高层次抽象：虽然有利于沟通，但这可能会限制详细设计。
   缓解措施：认识到 EventStorming 是一个起点，并准备好使用其他技术更深入地研究特定领域。

将 EventStorming 集成到 DDD 设计流程中

要在 DDD 上下文中有效利用 EventStorming，请执行以下操作：

1. 从Big Picture EventStorming开始：使用它进行初始域探索和边界上下文识别。
2. 进程级别 EventStorming 的进展：更深入地了解已确定的边界上下文中的特定进程。
3. 过渡到设计级别的 EventStorming：开始规划系统设计，识别聚合和关键域事件。
4. 补充其他建模：使用 UML 图或自定义表示法来捕获聚合、实体和值对象的结构详细信息。
5. 迭代和优化：持续优化模型，根据需要在 EventStorming 和其他建模技术之间移动。
6. 与实现保持一致：确保模型与所选的实现体系结构和模式保持一致。

如何在需要时定制 Evenstorming 词典。这里：以 UML 样式添加实体关系。为了清楚起见，建议使用单独的 UML 图。

最后的思考

EventStorming 的一个显著限制是它无法完全捕获域模型的结构方面，尤其是聚合（实体和值对象）。这个缺点通常需要用 UML 图或其他结构建模技术来补充 EventStorming 输出。对额外工具的这种需求引发了对 EventStorming 作为设计方法的完整性及其与 DDD 原则的一致性的质疑。

在我看来，EventStorming 通过提供“讲故事”的方法为模型描述增加了价值，这与人们自然描述业务需求的行为方面的方式密切相关。

围绕名词构建的领域模型揭示了基本的模型元素。聚合图，以及实体和值对象之间捕获的关系对于实现至关重要。然而，它并没有真正讲述系统应该做什么的故事。实施的原因是使用场景。它们是软件接受的起点，也是标准。场景帮助利益相关者以相对非技术性的方式理解域和系统行为以及系统意图。出于这个原因，我认为 EventStorming 输出可以用作模型的主干文档。如果需要，这应该通过 UML 图来补充，以添加所有必要的详细信息来支持实现。

此外，当在软件实现工具和架构模式的背景下考虑时，EventStorming 的真正力量就会显现出来。DDD 强调了将领域模型与实现技术保持一致的重要性。某些架构模式（如事件驱动架构、使用执行组件模型的反应式消息传递、命令查询责任分离 （CQRS） 和事件溯源）与 DDD 原则具有很强的协同作用。在这些情况下，EventStorming的系统设计级别作为一种建模语言大放异彩，有效地捕获和表达了核心系统概念。我将专门写一篇文章来介绍这个话题。

总结

通过了解 EventStorming 的优势和局限性，开发团队可以将其用作实施基于 DDD 的解决方案的坚实基础，这些解决方案准确反映已发现的领域知识。关键在于知道何时以及如何将 EventStorming 与其他技术相辅相成，以创建一个全面的领域模型，从而推动有效的软件设计和实现。

关键要点：

• 范式转变：EventStorming 提供了一种动态的、面向过程的领域建模方法，补充了 DDD 对静态结构的传统关注。
• 概念对齐：虽然直接映射到某些 DDD 概念（例如，域事件、聚合），但 EventStorming 隐含而不是显式地对其他概念（例如，实体、值对象）进行建模。
• 优势：擅长协作领域探索，促进通用语言开发，并与事件驱动的架构完美契合。
• 局限性：缺乏详细的结构表示，需要辅以其他建模技术以实现全面的 DDD 实现。
• 战略集成：当作为更广泛的建模策略的一部分使用时最有效，从Big Picture EventStorming开始，逐步进行更详细的级别，并根据需要补充其他DDD建模技术。