事件风暴教程

将大型复杂系统模块化为更小、更易于管理的部分是很好的最佳实践，不仅可以降低每个部分的认知负担，还可以实现团队独立性和操作弹性。棘手的一点是如何划定边界？为整个系统建立一个稳定和可持续的结构。基于有界上下文的领域驱动设计是一种方法，其中是使用领域语言作为指导，另一种方法是从业务模型定义

事件风暴与事件建模都是DDD建模方法，两种方法提出发明者不同，切入点不同，虽然都是以领域事件为抓手，eventmodeling.org原文如下：事件风暴EventStorming分为设计级别或流程级别，需要一些 DDD 知识，像“聚合”或“有界上下文”这样的词，对于非技术观众来说有点

如果您想学习或练习如何将大型企业分解为多个领域并将其用作软件架构和团队组织的基础，nick的个战略性的领域驱动Github项目可能会很有

真正价值是开发客户想要的功能，而不是基础CRUD功能：各种敏捷专家提供了一些有关用户故事切片/拆分的重要信息。但是，经常遗漏的一个关键方面是能力划分和功能划分之间的区别。通常认为，用户故事的关键要求是其实现应为您的产品或服务的用户带来价值。我的解释方式是，它应该讲一个故事，使

大多数学习事件溯源的人都是将其作为应用程序设计模式，当然这是事实。但是，使用事件溯源的主要原因是该模式激活了事件数据模型。我很早在80年代中期关系型数据开始兴起时就在关系型数据库领域工作。关系数据库采用的一个主要推动力是关系（相对于层次结构）不需要您锁定查询访问模式。当业务需

一旦您拥有多个微服务，就很难在一张图上显示所有微服务。建模方式有几个选项： （1）对图进行分区：显示每个单个的领域，有界上下文映射/业务能力等是一种很好的方法。 （2）也可以集中于单个微服务及其传入/传出耦合。例如：

功能feature代表了软件设计的基本复杂性。这是无法避免的复杂性。其他所有内容（语言，工具，模式等）都是意外复杂性的一种形式。因此，要编写最简单的代码（无论我们在堆栈的哪一侧），都应该采用功能驱动feature-driven的方法。它影响我们构造项目，编写测试，封装模块和设计功能的方式。<

业务事件(领域事件)是发生的事情，当它发生时，它会引起企业的预先计划的响应，或者在这里我们称之为“工作”。一类业务事件是在相邻系统内部发生的事情。使工作知道业务事件已经发生，因为每次发生都会为工作产生数据流。业务事件是一个重大事件，不仅仅是单击鼠标。通常，这是对您的企业提供的服务的请

CQRS中通常建议命令的处理要"干净"，实际上将其视为“无效函数void”。这种函数不返回任何业务结果，但可以返回操作状态或所需的元数据。在CQRS中，命令和查询的隔离基于操作行为。查询返回数据，并且不更改应用程序的状态；命令修改状态。这种隔离有助于创建松散耦合的组件，不断发展的解决

快速在线工具，用于创建序列图：https://sequencediagram.org/使用序列图实现事件动作的DDD建模视频：DDD 聚合设计在线视频：

当我们开始用事件建模我们的系统时，我们很容易掉入陷阱。我们习惯于从数据模型的角度来看待我们的功能：当你手里拿着一个关系数据库时，你会看到到处都是表格，因为

事件溯源从业者使用事件捕获方法（如事件风暴和事件建模）设计他们的领域。这项工作的输出通常是真实或数字白板上的大量便利贴。从这个模型中，开发人员必须填写很多关于命令、事件和读取模型的细节来构建一个工作系统。这个映射过程是手动的，发生在他们的脑海中。人工检查和测试套件可确保代码与即时贴匹配。这个

敏捷、进化设计、精益启动、精益软件开发等–所有这些都试图为您提供提高反馈水平的工具，为您实现渐进式设计提供了一种上下文。渐进式设计的工作原理是使系统一次增加一种功能，从而使设计到目前为止足以满足系统需求。随着需求的变化，系统会不断发展以满足他们的需求。进化设计面临技术挑战，但有限制的

用户故事映射通过一步一步的流程直观地显示用户浏览我们软件的过程，并在此过程中创建各种用户故事。与简单的积压订单相比，用户故事图在产品环境中增加了位置和移动的维度，使您可以先进行图绘制，然后浏览产品的整个用户空间。借助用户故事图，您可以在上下文中看到整个图景，而线性积压则不会那么多。我

使用Wardley Mapping讲故事需要一种完全不同的方法。通常，您的听众不了解映射，也不熟悉这些模式。第一个建议是从空白画布开始。空白的画布没有威胁性，它是一个空洞的东西，没有任何信息，但承诺了一些新的和令人兴奋的东西。你可以用一张空地图消除很