我刚进入事件驱动架构，想知道命名和事件的约定是什么。我知道这一点：命令应该是DoSomething的形式，而事件应该以SomethingHappened的形式出现。我需要澄清的是，如果我需要在我的命令中添加“命令”这个词，并在我的活动中添加“事件”，例如DoSomethingCommand，而不仅仅是DoSomething和SomethingHappenedEvent，而不仅仅是SomethingHappened。我也想知道社区偏好的公约背后的理由。谢谢！命令与事件的命名约定
Command和Event后缀是可选的，并且是偏好问题。我更愿意忽略它们，并试图从名字中明确表达意图。命名命令和事件最重要的方面是确保它们比技术领域更能反映业务领域。很多时候，诸如创建，更新，添加，更改等术语过于技术化，在业务领域意义不大。例如，不要说UpdateCustomerAddress，你可以说RelocateCustomer，它可能有一个更大的业务环境。
谢谢，我已经开始使用这种方法实施。我也喜欢@MikaelÖstberg关于使用名称空间的观点。我注意到的一个小点是事实/命令在实例化对象时看起来更好。比较： 'VAR userSignedOut =新UserSignedOut（）{};'' bus.Publish（userSignedOut）;' 与 '变种userSignedOutEvent =新UserSignedOutEvent（）{};'' bus.Publish（userSignedOutEvent）; ' – Tolu
我的约定取决于命名空间，我的意思是我从不使用后缀事件和命令。
我还将命令和事件组织到单独的命名空间中，这些命名空间基于它们意图影响的聚合类型。
例子：
// 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
根据您可能想将您的活动到一个单独的装配您的要求。这是因为您需要将事件分发到下游系统。在这种情况下，您可能不希望下游系统不得不打扰您的命令（因为它们不应该）。
非常感谢，@ mikael。这很有意义，也是我目前倾向的方向。我只想澄清标准做法是什么。 – Tolu
我不会说这是标准做法。这只是我做这件事的方式。但是，我认为这遵循.Net惯例使用名称空间作为全名的一部分，而不是用后缀和东西重复自己。唯一的缺点是，当你想为名为'Created'的20个事件中的一个添加using语句时，resharper提供了很多选项。 –
我倾向于将我的命令和事件分离为单独的程序集，并使用不同的命名空间，如上面所述的@MikaelÖstberg。我也不会主张在这些消息的末尾加上命令或事件。 +1 –
如果命令/事件命名正确，那么追加命令和事件将成为冗余信息。这将是噪音，使您的代码不易读。记得匈牙利语？大多数程序员（我知道）不再使用它。
命令和事件形成一个语言为您的应用程序...一个API。像'command'和'event'这样的术语对于系统级定义可能很有用，其中技术术语被有意义地混合到一个实体的目的中，但是如果你正在处理域行为的定义，那么放弃系统/技术术语和青睐业务发言。它会让你的代码更自然地阅读并减少打字。 我从'命令'/'事件'附件开始，但意识到这是浪费时间，并使我远离普及型语言DDD的普及。 HTH， 迈克
，我已经看到了很多和自己使用的约定是，事件应该是过去时态和描述所发生的事情：
命令是你想要做的事情。因此，创建说明名称：
至于组织，我通常把它们放在一起与根总认为他们是。它使您更容易看到您可以做什么以及生成哪种事件。
也就是说，我为每个根集合创建了一个名称空间，并将所有的东西放在它下面（存储库定义，事件，命令）。
等
谢谢！刚刚做到了。花了一点时间来弄清楚如何。 – Tolu