我剛進入事件驅動架構，想知道命名和事件的約定是什麼。我知道這一點：命令應該是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