7、微服务开发：从事件风暴到首个微服务创建

微服务开发：从事件风暴到首个微服务创建

1. 事件风暴会议

事件风暴会议从记录领域事件开始。领域专家们先在橙色便利贴上写下脑海中浮现的任何领域事件，然后将其贴到墙上。随着会议推进，当回忆起或思考出其他事件时，再添加更多便利贴。在讨论过程中，若发现新的事件顺序，还会重新排列这些便利贴。

在这个阶段，无需记录所有领域事件。随着会议进行和更多便利贴的添加，会将其他领域事件融入故事情节中。除非存在关键业务功能，否则无需记录持久层（数据存储交互）的功能，因为持久层不应包含业务逻辑，否则代码不够简洁，且会导致依赖关系更紧密。

与问题空间无关的领域事件不应出现在墙上。例如，“用户登录系统”这一领域事件，只有当问题涉及用户登录时才应记录，否则只会造成混淆。而与通知客户和承运商相关的领域事件，由于直接适用于问题空间中的业务流程，所以应记录在墙上。

在贴上领域事件后，需让团队查找无需保留在板上的重复事件，并确定事件顺序。不过，有些重复事件是有必要保留的，比如通知承运商的事件可能会多次发生，但它们都有特定的上下文。

之后，让领域专家记录领域事件的其他支持部分，如操作/命令、聚合、参与者和策略等，并将它们放置在相应位置，以更清晰地展示业务流程的运作方式。通常需要移动许多便利贴来为新增的支持便签腾出空间。聚合也可能出现重复便利贴的情况，例如在不同上下文中可以使用“Load”“Customer”“Carrier”和“Invoice”的副本，这种情况下使用副本比移动便利贴更清晰。

随着团队对墙上的便利贴进行审查和讨论，不同的上下文开始形成。例如，创建负载请求的上下文涉及“Load”聚合和“Customer”参与者；创建报价的上下文则依赖于管理员“An