事件风暴中如何识别聚合？

事件风暴是一种强大的技术，用于映射不同抽象级别的系统的复杂性。这种协作方法使团队能够可视化并理解域内的事件、操作和策略的流程。 

大局级别
在事件风暴的大局层面，主要目标是建立系统的总体视图。该阶段是整个过程的基础。参与者协作确定系统内的主要域或子域，通常称为“大局”上下文。这些上下文代表在系统运行中发挥重要作用的高级功能区域或组件。此级别的目的是让利益相关者全面了解系统的结构和架构。便利贴和大画布用于直观地表示这些上下文，每个上下文都被命名并简要描述。这种可视化提供了整个系统景观的清晰度，并有助于在核心领域和重点领域上协调利益相关者。

在此阶段，参与者还重点关注识别和记录系统内的潜在冲突。由于不同领域之间的职责重叠、资源分配或目标冲突，可能会出现冲突。尽早认识到这些冲突可以让团队主动解决这些冲突，从而最大限度地减少设计和开发后期阶段的挑战。

除了冲突之外，大局级别的参与者还致力于定义系统的目标。这些目标作为驱动系统设计和功能的指导原则。清晰且明确的目标有助于确保后续的设计决策与系统的预期目的和目标保持一致。

阻碍因素是可能阻碍系统进步的障碍或约束，是此级别的另一个关键考虑因素。在流程的早期识别阻碍因素使团队能够制定策略来有效地克服它们，从而确保更顺利的系统实施。概念边界定义每个域或子域的范围和上下文。了解这些边界对于确保系统在其定义的约束内无缝运行至关重要。

大局是解决这些要素的起点，使利益相关者能够深入了解系统内更广泛的挑战和机遇。这种全面的视图不仅有助于理解系统的结构，而且还为事件风暴期间在后续抽象级别中处理这些元素奠定了基础。

流程级别
事件风暴的流程级别更深入地研究每个已识别的上下文或域内的特定业务流程或工作流程。参与者协作定义这些过程中发生的事件和操作的顺序。主要目标是可视化并理解驱动系统行为的操作和事件流。此级别有助于揭示流程中的依赖性、触发器和结果，提供系统如何响应各种输入和事件而运行的全面视图。便签广泛用于表示流程中的事件和命令，并且流程映射在画布上。这种视觉表示清楚地显示了事件和操作如何相互联系以实现特定目标，从而提供对流程工作流程的深入了解。

在流程级别，确定价值主张至关重要，它概述了系统或流程为其用户或利益相关者提供的核心优势。了解价值主张有助于参与者将他们的努力与总体目标结合起来，并确保设计的流程有助于交付价值。策略代表控制系统内如何处理事件的规则、指南和业务逻辑。他们定义了各种场景的行为和决策标准。在事件风暴期间识别策略可确保参与者考虑影响流程的监管和合规方面。

角色是代表不同类型的系统用户的虚构人物或用户配置文件。这些角色有助于理解最终用户并理解他们的需求、目标以及与系统的交互。将角色纳入流程级别使参与者能够设计满足特定用户需求的流程。个人目标是指系统内各个参与者或参与者的目标和意图。确定个人目标有助于确定不同利益相关者的动机和预期结果。它确保流程符合相关各方的不同目标。

设计级别
在事件风暴的设计级别，重点转移到系统内各个组件或聚合的内部行为。参与者共同对控制这些组件行为的命令、事件和策略进行建模。此级别允许更精细地探索系统行为，使参与者能够定义系统不同部分之间的契约和交互。便签继续用于表示此级别的命令、事件和策略。这些注释提供了组件内部工作的详细视图，说明了它们如何响应命令、发出事件和执行策略。设计级别对于定义每个组件内的行为和逻辑至关重要，确保系统按预期运行并与业务目标保持一致。

识别聚合
事件风暴与领域驱动设计 (DDD) 的原理和词汇错综复杂地交织在一起，以建模和阐明技术概念。我们达到了领域驱动设计 (DDD) 的一个关键且通常具有挑战性的方面——理解和识别聚合。尽管聚合是 DDD 的基本组成部分，但它通常是工程师最不了解的概念之一。这种缺乏清晰度可能会导致系统设计和实现中出现重大缺陷。聚合不仅仅是对象的集合；它们代表围绕一组实体和值对象精心设计的边界。这些边界对于维护数据完整性和封装业务规则至关重要。
然而，工程师经常难以理解聚合的最佳大小和范围，导致聚合过大成为瓶颈，或者导致系统出现不必要的复杂性。（banq注：缺乏上下文概念）

在设计级事件风暴的复杂过程中，特别是在识别和定义露营车租赁服务等复杂系统的聚合时，最重要的一步是确保正确的人员组合的参与并改变人员。理想情况下，这个团队应该由领域专家和技术专家（例如软件开发人员和架构师）组成，他们对露营车租赁业务有深入的了解。他们的综合见解对于确保确定的聚合符合业务现实和技术可行性至关重要。此外，让关注用户体验的个人参与进来是非常宝贵的，特别是对于直接与客户交互的系统方面。

一旦组建了这个多元化且知识渊博的团队，关键的第一步就是重新审视并反思从流程层面获得的见解。此阶段至关重要，因为它提供了有关业务工作流程、关键事件、命令以及之前识别和探索的复杂策略的丰富信息。正是在这个时刻，对业务运营方式的深入理解成为最重要的，提供了细致入微的视角，这对于下一阶段的聚合识别和设计至关重要。

在事件风暴中，流程通常从命令（启动的操作）到 域事件（系统中的重大更改或结果）。然而，通常有一个基本的业务规则来规定从命令到事件的转换如何以及为何发生。这就是空白黄色便签的用武之地。空白黄色便签充当将命令连接到域事件的业务规则的占位符。它表示命令导致事件发生必须满足的决策逻辑或标准。

业务规则与逻辑
当识别出命令及其相应的领域事​​件时，会在它们之间放置一张空白的黄色便签。这意味着有一个业务规则在起作用，影响着从命令到事件的转换。便利贴的空白状态邀请团队成员，尤其是领域专家，讨论并确定具体的规则或逻辑。这是一个协作过程，不同的观点有助于准确定义规则。通过讨论，团队对业务规则有了清晰的认识。参与者被要求在黄色便利贴上填写这些业务规则，并提供有关其执行的全面详细信息。这涉及到几个关键方面：

• 先决条件：执行规则之前必须满足什么条件？例如，在“租赁露营车”命令成功之前，先决条件可能是所选露营车必须在所选日期可用。
• 后置条件：执行规则后什么会变为真？露营车租赁后，后置条件是露营车的状态在指定期限内更改为“已租用”。
• 不变量：在规则的执行过程中什么保持不变？一个不变量可能是客户的帐户必须在整个租赁过程中保持良好的信誉。
• 附加信息：有助于理解业务规则用途的任何其他说明或细节

此外，仔细研究与露营车相关的运营挑战和数据凝聚力巩固了我们的想法。我们意识到，在统一系统下管理与露营车相关的各个方面将简化运营、降低复杂性并提高服务效率。不同的信息——维护计划、预订日历、位置跟踪——都表明需要一种综合方法。

建立总量的决定是这些观察和讨论的结果。这一决定不仅是由运营逻辑驱动的，也是由与露营车相关的业务活动的自然融合驱动的。通过形成这种聚合，我们设想了一个系统，可以对露营车生命周期的各个方面进行统一管理，确保无缝运营和增强的客户体验。

强制执行一致性
这种方法还凸显了在露营车车队中强制执行一致性的必要性。通过设计一个聚合来封装与每辆车相关的所有方面，我们确保任何更改（无论是租赁状态更新还是维护检查）都能在整个系统中得到一致反映。这种一致性对于维持我们服务的完整性和可靠性至关重要。例如，如果露营车计划进行维护，则不应可供预订。同样，每辆露营车的位置信息都需要准确且最新，以确保高效的车队管理。

想象一下这样一个场景：客户预订了一辆露营车从慕尼黑到巴黎的旅程。在聚合中，每个露营车的几条信息都被跟踪和管理，包括其当前位置、可用性状态和维护计划。当客户为他们的日期选择特定的露营车时，聚合会立即将车辆的状态更新为该期间的“租赁”。此更新对于确保同一日期的其他客户无法使用同一辆露营车，从而防止重复租赁至关重要。

同时，假设这辆所选的露营车将在客户建议的归还日期后不久进行维护。该系统遵循聚合内的规则，标记该露营车进行维护，确保在维护完成之前它不会被再次出租。

不变量或必须始终成立的规则成为聚合设计的基石。这些不变量强制执行关键业务规则并确保系统始终有效。例如，我们系统中的一个不变量确保露营车不能同时被预订和标记为维护中。这些不变量对于维护数据完整性和为客户提供一致、可靠的服务至关重要。

让我们考虑一个现实生活中的场景来说明这一点：一个家庭热切地计划从慕尼黑到风景如画的巴黎的夏季公路旅行。他们在我们的网站上找到了完美的露营车，并开始租用它进行冒险。他们看不到，但对他们的旅程至关重要的是，我们的不变量在发挥作用。

一旦他们选择了日期和露营车，系统就会立即启动。它会检查总数，特别是探测两个关键条件 - 所选的露营车是否已在这些日期租用，是否需要维护？这就是不变量发挥其影响的地方。它坚定地确保这辆露营车既不会进行另一次旅行，也不会在要求的时间内安排进行维护检查。这条规则是不灵活的，是我们对可靠性承诺的基石。

这些嵌入在我们聚合中的不变量不仅仅是代码行或业务策略。它们是一个承诺——一个没有意外的冒险的承诺，一个创造回忆而不是不幸的旅程的承诺。通过确保每辆露营车都做好充分准备并可用于每次预订，这些规则不仅使我们的运营保持平稳，而且巩固了我们作为可靠和以客户为中心的企业的声誉。

在我们通过事件风暴探索露营车租赁业务的过程中，我们确定了许多单独的事件、命令和策略。然而，只有当这些元素作为一个有凝聚力的单元聚集在一起时，它们才具有真正的意义。这种聚类构成了聚合的本质。这是一个概念性的认识，即租赁、维护计划、客户互动等孤立的部分是相互依赖的，共同构成了我们服务的核心。如果没有这种统一，每个元素都将仅仅存在于真空中，缺乏背景和影响。

这个聚合的核心，它的根源，是露营车本身。露营车不仅仅是一个物理实体，而且是各种业务流程和客户体验的纽带。我们选择露营车作为聚合根，因为它是所有其他活动围绕的中心元素。无论是预订露营车、为客户做准备还是安排维护，每项操作都直接与个人露营车相关。这一选择反映了我们的理解：露营车是我们业务模式的关键，直接影响客户满意度和运营效率。
 
聚合的命名
这一步策略性地放在会议结束时，它不仅仅是一个标记练习；这是提炼和综合整个活动中获得的见解的最后一步。在会话的早期，可能会很想为这些聚合指定名称。然而，这种冲动遭到抵制，因为过早命名可能会导致误解。过早给出的名称可能无法完全捕捉聚合所代表的本质，因为它们基于对系统的初始、不完整的理解。因此，等到最后才命名这些聚合的做法不仅仅是一个程序步骤；而是一个步骤。这是为了确保命名的准确性和相关性而经过深思熟虑的选择。
 因此，以露营车为根的露营车聚合体成为我们系统架构中的强大工具，将我们操作的复杂性封装到一个可管理且连贯的结构中。