領域事件與最終一致性
領域事件 代表了領域中發生的某些事情, 當Eric Evan 原創的 DDD 書本 發行的時候并沒有把它定義為一種 領域驅動設計 (DDD) 模式，但現在在DDD中已經是一種戰術元素，而且是一個完整的領域模型成員。 最終一致性 是一種改進規模和性能的設計方法，而且領域事件能作為觸發器承載領域信息進而協助實現， Florin Preda 在最近的 博客文章 中作出了解析.
對于多數開發者都很熟悉的事務型一致性工作流中，客戶在系統中執行一個命令，這個系統為維護事務中的領域一致性的需要而運行所有操作。當操作全部成功或全部失敗的時候客戶會收到反饋，沒有中間地帶。
對于常見于分布式系統的最終一致性工作流中，客戶同樣在系統中執行一個命令，但這個系統只為維護事務中的領域一致性運行部分的操作。剩余的操作在系統前后一致后運行。
Preda指出雖然事務型一致性看起來更加直觀和容易使用，但他覺得某些場景中最終一致性有一點優勢。在他描述的四種場景中，用A操作之后進行B操作來作為例子：
Preda將場景3和4關聯到領域驅動設計（DDD），他相信在這兩種場景中選擇最終一致性將引導到比使用傳統事務工作更好的設計。領域事件在這里可以很有用。領域事件是在領域專家相關的領域中發生的某些事情的代表，它們通過作為觸發器啟動工作流的下一個步驟和承載領域信息需求來促進最終一致性。
寫同一主題的 Mike Mogosanu 聲稱在現實世界的用例中 事務型一致性工作流很罕見 ；一個業務流程經常包含一系列的用例和使用 Unit of Work (UoW) 模式去持久化一組更改，從技術觀點來看，它幼稚的解決方案會將事情復雜化，尤其是在分布式應用中。
Mogosanu相信一個包含不同有界上下文的業務流程應該考慮變為最終一致性，其在每個有界上下文中有最少一個領域用例。領域用例負責讓聚合保持始終如一，在這里UoW模式會很有用，而且公布觸發其它用例啟動的領域事件，最終可以把整個系統帶到一致的狀態。
為了舉例說明他的想法，在實現用 Azure Service Bus 消息系統來做事件傳送的C# 應用 中，Preda使用了 Vaughn Vernon 在書本 實現領域驅動設計 中提到的設計的一個簡化版本。
查看英文原文： Domain Events and Eventual Consistency