命令和事件的命名约定

Question

我刚刚进入事件驱动的体系结构,并想知道命名命令和事件的约定.我知道的很多:命令应该是DoSomething形式,而事件应该是SomethingHappened形式.我需要澄清的是,如果我需要在我的命令中附加"命令"一词,并在事件中添加"事件",例如DoSomethingCommand,而不仅仅是DoSomething和SomethingHappenedEvent,而不仅仅是SomethingHappened.我还想知道社区首选公约背后的理由是什么.谢谢!

Answer 1

在Command和Event后缀是可选的,是偏好的问题.我更喜欢省略它们,并试图仅从名称中明确表达意图.命名命令和事件的最重要方面是确保它们比技术领域更能反映业务领域.很多时候,诸如创建,更新,添加,更改这些术语过于技术化,在业务领域中意义不大.例如,而不是说UpdateCustomerAddress你可以说RelocateCustomer哪个可以有更大的业务背景.

Answer 2

我的约定取决于名称空间,我的意思是我从不使用后缀Event和Command.

我还根据它们要影响的聚合类型将命令和事件组织到单独的命名空间中.

例:

// Commands
MyApp.Messages.Commands.Customers.Create
MyApp.Messages.Commands.Orders.Create
MyApp.Messages.Commands.Orders.AddProduct

// Events
MyApp.Messages.Events.Customers.Created
MyApp.Messages.Events.Orders.Created
MyApp.Messages.Events.Orders.ProductAdded

根据您的要求,您可能希望将事件放入单独的程序集中.这样做的原因是您需要将事件分发到下游系统.在这种情况下,您可能不希望下游系统不得不打扰您的命令(因为它们不应该).

Answer 3

命令和事件形成应用程序的语言……API。使用“命令”和“事件”等术语对于系统级定义可能很有用，其中技术术语有意义地混合到实体的目的中，但如果您正在处理域行为的定义，则放弃系统/技术术语并有利于商业演讲。它将使您的代码阅读起来更自然并减少打字。我从“命令”/“事件”附件开始，但意识到这是浪费时间，并让我远离了普及的无所不在的语言 DDD。HTH，迈克

Answer 4

我经常看到并使用自己的约定是，事件应该是过去时并描述发生的事情：

• 用户注册
• 帐户已激活
• 已回复

命令是您想做的事情。因此，创建说明这一点的名称：

• 创建用户
• 升级用户账户

至于组织，我通常将它们与它们所针对的根聚合放在一起。它使查看您可以做什么以及生成的事件类型变得更加容易。

也就是说，我为每个根聚合创建一个命名空间，并将所有内容（存储库定义、事件、命令）置于其下。

• MyApp.Core.Users
• MyApp.Core.Posts

等等。