有什么改进/改变，以及如何推进我的事件风暴会议？

Question

我正在为我的应用程序单独处理事件风暴，我计划稍后使用DDD方法构建应用程序。事件风暴会议是为了学习目的。

我的应用程序域逻辑相当简单。该应用程序称为“车辆维修管理系统”(VMM系统)。下面是应用程序的一些一般规则和逻辑：

• 用户可以注册、登录、重置密码以及更新有关帐户的一些基本信息，因此一些真正基本的用户管理逻辑。
• 用户可以添加/删除/更新他的汽车数据(这里是典型的CRUD操作)。
• 应用程序的主要目标是用户可以替换某些汽车的部件，以获得有关在车辆中使用的汽车部件的有效信息。系统可以根据汽车的里程或日期通知某些部件更换的截止日期。

因此，我做了一个事件风暴会议，包括大图片和级别处理步骤。我这次会议的结果是下面的截图：

这是我的颜色的一个传说：

我的问题是我这样做是正确的吗？你看到在我的会话中有什么东西可以改进吗？我接下来该怎么办？

我发现了四个聚合体：

• 用户
• 汽车管理
• 零件管理
• 通知

在我看来，应该有两个共同的根源：

• 用户
• Can管理(使用部件管理聚合对汽车零部件进行操作)。用户不应该能够直接访问部件管理聚合)

我在这里想得对吗？我想尽可能地理解这一点--任何建议都是非常感谢的:)

Answer 1

我收到的最大的建设性批评是，你仍然在很大程度上是一个残酷的心态，而不是一个事件来源的心态。一般来说，限制您用来描述概念的语言：

• 聚合根:简单复数名词。即用“汽车”代替“汽车管理”或“用户”代替“用户”。
• 事件:过去时动词。也就是说。“验车”
• 命令:现在时动词。也就是说。“检查车”

用客户的领域术语来解决这个问题。考虑到零件或库存管理功能的想法。有了这个特性，零件是库存，车库必须有手头，以执行维修的汽车。所以他们有一个独立的系统。您是否称其为“部件”、“库存”或“库存”取决于您的客户使用的领域术语。

部件

• 命令: Ordered ->事件:订购部件
• 命令:接收订单->事件:已接收部件
• 命令:股票部分->事件:部分库存
• 命令:检查库存->事件:库存更正
• 命令:拉出部件->事件:部分已拉
• 命令:返回部件->事件:部件返回(向制造商，即缺陷)

在上述每一种情况下，我们都不讨论创建、读取、更新、删除(CRUD)操作。这些都是以数据库为中心的概念。我们讨论的是用户在管理部件时需要执行的操作。当我们重播域事件时，我们应该能够得到相同的状态。

事件源与事件发送

在我们的行业中，“事件”这个词已经超载了。有些团队选择用事实这个词代替事件来描述我们储存和回放的东西，以达到我们目前的状态。另一个常见的词是消息，用于引用用于异步执行工作的活动消息。无论您选择什么，如果您同意使用术语来描述来自通知事件的事件源事件等，那么对于您的团队来说将是非常有用的。

深入挖掘

一旦你找到了可能发生的事情，你就需要弄清楚在这个事件中需要什么信息。您不需要所有的东西，但是每个事件都应该有一个时间戳，一个可以将事件属性化的用户，以及被更改的实际信息。