Domain driven design UserRegisteredEvent与RegisteredUserEvent命名

我们公司开始使用领域驱动设计，我想知道如何命名事件

我正在犹豫：

• UserRegisteredEvent

  ：因为它是“用户寄存器”的过去时

• RegisteredUserEvent

  ：因为英语中形容词应该排在第一位

UserRegisteredEvent

从我在互联网上找到的信息来看，似乎是正确的

但我想知道的是，如果这个人不是像发短信那样做动作的人：

• 已发送文本消息=>

  SentTextMessageEvent

• 用户发送TextMessages=>

  UserSentTextMessageEvent

  （有点冗长，我们并不在乎它是由用户完成的）
• TextMessage不发送自身=>

  TextMessageSentEvent

=>这方面的最佳实践是什么？ =>我应该区分

UserRegisteredEvent

（用户自己注册）和

RegisteredUserEvent

（有人注册了新用户）吗

---

谢谢大家!

事件是发生在过去的感兴趣的事情，所以你用过去式的句子来命名它。在您的示例中：

用户已注册

短信已发送

---

要缩写名称，可以省略“was”。但是“注册”不是一个形容词。

当与业务涉众密切合作时（这是利用领域驱动设计的主要支柱之一），命名部分在大多数情况下非常明显。业务人员已经知道如何命名系统的哪个部分发生了什么

系统的哪个部分会给你相关实体（或对象）的名称，而发生的事情会给你一个动词的过去式

当在源代码中命名域事件时，我们提供了一些可读的事件摘要，这使得它可以从业务角度快速识别为相应的事件

您在问题中查看了两种不同的命名模式：

• 模式A：开头的过去时动词
  • 登记器
  • SentTextMessage
  • 船运订单
  • 交付弧
• 模式B：结尾处的过去时动词
  • 用户注册
  • 短信发送
  • 订单装运
  • 包裹的

附加…事件后缀（例如UserRegisteredEvent）当然是有效的，附加后缀与否几乎总是根据与我一起工作的团队的偏好来决定的

当谈到<强>域事件< /强>时，您还必须考虑<强>域命令< /强>。对于域命令，您还可以添加…命令后缀。该命令表示一个命令，告诉您该做什么，其中涉及一些实体（或对象）和一些描述动词的命令形式

例如：

• 船票
• 登记员
• SendTextMessage

因此，让我们再次看一看问题中的以下事件名称，作为一个示例，使用开头带有过去时动词的模式（模式A）：

• 因为英语中形容词应该排在第一位

• 已发送TextMessage=>SentTextMessageEvent

在所有情况下，当我应用领域驱动设计时，我们都同意使用另一个模式，其中过去时动词位于末尾（模式B）和，以下是原因：

事件的名称应能快速识别，并且-这对我来说也是非常重要的-可与命令区分，即使不使用…事件和…命令后缀

当我看到以下使用模式a的命令和事件示例时，作为一名读者，我感到很难过：

• SentTextMessage（事件）与SendTextMessage（命令）
• RegisteredUser（事件）与RegisterUser（命令）

但是，当我使用其他形式的事件命名（模式B）时，对所有相关人员来说，无论是在图纸、书面架构文档、源代码中，都会变得容易得多，例如：

• TextMessageSent（事件）与SendTextMessage（命令）
• UserRegistered（事件）与RegisterUser（命令）

---

不客气！我了解到，从更大的角度来看这些问题总是有帮助的。这就是为什么，例如，命名事件应该在整个上下文中考虑，其中包括命名命令（以及其他）。