horizon client 无法识别域_「领域驱动设计DDD」事件风暴简介：实现域驱动设计的简便方法...

事件风暴是一种快速，轻量级且未得到充分认可的群体建模技术，它对于加速开发团队而言非常强大，有趣且有用。作为Alberto Brandolini的心血结晶，它是Gamestorming和领域驱动设计（DDD）原则的综合学习实践。该技术不限于软件开发。您可以将其应用于几乎任何技术或业务领域，尤其是那些大型，复杂或两者兼而有之的领域。

事件风暴催化并加速小组学习，通常在几小时或几天内实现更传统的建模技术从未做过的事情 - 对软件必须运行的领域的共同理解。

要了解事件风暴，您首先需要了解两个关键术语。域事件是域专家感兴趣的任何事件。域专家对数据库，Web套接字或设计模式不感兴趣，但对业务领域感兴趣。域事件以不指定特定实现的方式捕获这些事实。

事件风暴如何运作

您运行一个辅助研讨会进行一个活动风暴会议。每个人都参与其中，并且协调人使团队保持专注和参与，指导进展到完整的域模型。该小组从域事件开始，向前和向后遍历模型以确保所有内容都被覆盖。然后，该组添加导致事件的命令或触发器，并考虑所有命令源，包括用户，外部系统甚至时间。

该组识别接受命令和完成事件的聚合，并开始将聚合分组到有界上下文中。在此过程中，识别关键测试场景，用户和目标并将其合并到模型中。最后，添加有界上下文之间的关系以创建上下文映射。然后用代码对所得模型进行挑战，以验证组学习并验证模型。

虽然DDD社区的事件风暴正在增长，但在该专业之外几乎不为人知。这是一种耻辱，因为只有主持人必须是DDD从业者才能指导小组走向完整的模型。包括非技术产品所有者在内的每个人都可以参与对域的理解和建模。整个团队了解域越好，软件实施越有可能反映域，这是DDD的主要目的。

走得更快

如果你可以完成这个项目，你刚刚重新完成了，同一个团队，知道你现在知道什么，你能够更快地完成它吗？

是的，因为你已经学会了成功所需要的知识。小组学习速度慢是软件开发过程中的主要制约因素。正如Brandolini所说，“软件开发是一个学习过程;工作代码是一个副作用。”

域事件有助于构建域模型;它们起到了骨骼的作用。这不是设计，它是关于域的模型 - 一个视角。您使用域事件来推动建模，因为技术人员和领域专家都很容易理解。域事件几乎没有关于设计的说明，也没有关于实现的内容，这正是你想要的一个好的域模型。

一种不同的建模方法

更传统的DDD建模工作通常由小组或个人开发人员完成，有时在与产品所有者就数据，对象或行为进行几次对话之后。不幸的是，这开始建模的程度太接近实现域，而不是局限于业务领域。如果您从数据建模开始，您的思考和对话将很快转移到模式，事务和其他与业务领域无关的事情。如果从行为建模开始，当您将行为分解为任务并将其链接到流程时，您会分心。

这些是实现概念，而不是业务领域概念。虽然有很多选择来表示数据和实现行为，但域事件没有其他选择。由于域事件表示域的事实，因此这些事件仅在基础业务发生更改时才会发生显着变化。因此，域事件是您模型的更稳定和更具弹性的脚手架。

但是这种方法有一个更令人信服的理由：将初始讨论限制在域事件中会迫使每个人，特别是开发人员，专注于域的无处不在的语言。他们必须学习它，定义它，改进它，并在有关模型的对话中专门使用它。

虽然以域事件为中心的模型可能会自然地导致事件驱动的系统设计(EDA)，例如事件源或命令查询责任隔离(CQRS)，但这是一种选择，而不是义务。实现模型的软件不必是事件驱动的，甚至不是面向对象的（尽管这些通常是很好的选择）。

加速小组学习

想想你完成的最后一个项目。开发人员必须做些什么才能理解域模型并构建系统？在发挥故事的过程中，开发人员可能会在域专家，解决方案架构师，测试用户和其他团队成员之间穿梭。虽然这个过程可能会导致所有团队成员对整个域的共同理解，但这不太可能。转移的领域知识过于稀疏，过于分离，过于孤立，而且过于分散，无法在任何单个开发人员的脑海中产生完整的模型，更不用说整个团队理解的常见模型。

相反，这些对话可以在事件风暴会话期间发生。通常这些对话是按顺序发生的，但是在事件发生时，它们都会立即发生。通过这种方式，您可以解决域中任何部分的任何冲突或不连续性，同时所涉及的每个人都在场并参与其中。

DDD的最大障碍是开发人员倾向于专注于他们非常了解的事物 - 软件开发概念 - 而不是业务领域。当非技术人员（例如产品所有者或用户拥护者）与开发人员会面并开始用编程术语而不是商业术语描述系统时，可以看到这种情况的一个症状。如果开发人员不了解域，则无法正确建模。

何时何地使用事件风暴

使用事件风暴最明显的时间是在项目开始时，因此团队可以从对域模型的共同理解开始。使用事件风暴的另一个高回报时间是项目结束的一部分，用于捕获和分享团队在构建软件过程中学到的知识。这很重要，因为没有任何一个开发人员可能因为偶然的发现，修改以及对其他区域的有限暴露而了解整个域。使用较小规模的事件风暴也是有利的，例如当您考虑改变某些事物，开始新故事或制定不同的场景或替代方案时。