Question

我刚刚进入事件驱动的体系结构，并且想知道命名命令和事件的约定。我知道的很多：命令应该是DoSomething形式，而事件应该是SomethingHappened形式。我需要澄清的是，如果我需要将“命令”一词附加到我的命令中，并将“事件”附加到我的事件中，例如DoSomethingCommand与DoSomething和SomethingHappenedEvent相反，而不仅仅是SomethingHappened。我还想知道社区首选公约背后的理由是什么。谢谢！

Answer 1

Command和Event后缀是可选的，是首选项。我更喜欢省略它们，并试图仅从名称中明确表达意图。命名命令和事件的最重要方面是确保它们比技术领域更能反映业务领域。很多时候，诸如创建，更新，添加，更改之类的术语过于技术化，在业务领域中意义不大。例如，您可以说UpdateCustomerAddress而不是说RelocateCustomer，而{{1}}可能会有更大的业务背景。

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

如果正确命名了yor命令/事件，则追加命令和事件将是冗余信息。这将是噪声，使您的代码可读性降低。还记得匈牙利表示法吗？大多数程序员（我所知道的）不再使用它了。

Answer 4

命令和事件构成了应用程序的语言 ... API。使用诸如“命令”和“事件”之类的术语可能对系统级定义很有用，其中技术术语有意义地混合到实体的目的中，但如果您正在处理域行为的定义，则删除系统/技术术语和赞成商业发言。它将使您的代码更自然地阅读并减少输入。我从“命令”/“事件”附件开始，但意识到这是浪费时间，让我远离泛无处不在的语言DDD。 HTH，麦克

Answer 5

我已经看过很多并且使用自己的惯例是，事件应该是过去式并描述发生的事情：

UserRegistered
AccountActivated
ReplyPosted

您希望执行命令。因此，创建说明以下内容的名称：

CREATEUSER
UppgradeUserAccount

至于组织，我通常将它们与它们所针对的根聚合放在一起。它使您可以更轻松地查看可以执行的操作以及生成的事件类型。

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

MyApp.Core.Users
MyApp.Core.Posts

等

命令的命名约定＆amp;活动

5 个答案: