幾周前，我結束了一場技術辯論，討論如何進一步利用現有的事件溯源應用程式，以充分利用其旨在為您帶來的好處。我已經寫了許多帖子是關於陷阱、最佳實踐以及如何在.NET中具體實現這一點。但是我仍然認為為您提供一些最重要的指導方針和啟發式方法列表可能是有用的，我認為這些列表和啟發式方法對於成功使用事件溯源是必不可少的。

除非您擁有一個複雜的域，該域必須處理在同一實體上一起工作的許多使用者，否則請不要使用事件源。您不需要僅用於構建稽核日誌的事件源。即使您確實使用事件源，也可能不需要所有內容。通常，主資料也可以使用版本化架構進行處理。但是話又說回來，對於較小的團隊，只有一個正規化可能會更好。但是不要忽略NoSQL作為事件源的替代方法。

不要圍繞不變性建模，而是圍繞業務概念或資料模型對聚合建模。但是要小心，選擇系統必須保護的不變性，以及可以使用更函式化的方法（或跨聚合的事務）來解決哪些不變性。如果不這樣做，最終將產生巨大的聚合。（banq注：跨聚合事務是一種最終一致性事務）

不要對跨聚合事務教條主義，僅當您確實需要效能和併發性時，才強制每次事務僅涉及一個聚合。否則請保持務實。如果沒有事務邏輯來保護跨聚合實現業務規則的複雜性，這可能是非常具有挑戰性的，通常不值得。

請為每個聚合分配一個（自然的）分割槽鍵，這樣，如果出於效能或儲存方面的考慮，如果您需要你能用它來拆分事件儲存。

一定要將事件儲存視為業務中發生的重大稽核日誌，並且永遠不要更改或重新排序事件。確保您可以明確指向事件儲存中的某個位置，並檢視在該檢查點編號之後發生了哪些事件。這對於具有增量資料遷移的分散式事件儲存和藍/綠部署可能非常有用。但是，多年來我們一直在使用自己的Event Sourcing，因此能夠從事件儲存中診斷生產問題對我們至關重要。

不要把事件當作捕捉屬性變化的一種方式。當開發人員將事件溯源作為技術解決方案而沒有充分了解業務領域和/或不邀請業務人員參與時，通常會看到這種所謂的屬性來源。考慮使用事件風暴或事件建模作為對映業務流程的技術，而不是專注於資料模型。

不要將域事件用作域或服務之間的通訊機制。事件源是特定域（或DDD術語中的有界上下文）的實現。使用更多的粗粒度事件進行域間通訊，例如，通過將域事件投影到推送到訊息匯流排或API閘道器的更高階別的事件中。

不要為了加快投影速度而改變事件。CQRS的全部要點是您將命令端（域）和查詢端（預測）之間的利益衝突分開。當業務域更改時，聚合和事件也會更改。當顯示/查詢需要更改時，投影也會更改。

根據功能需求明確說明要在事件中保留哪些資訊。因此，如果您需要使用者簽署文件的全名，請使其成為事件的一部分。如果您只需要最新的全名，請計劃相關事件。

請為事件提供唯一的識別符號，並使用該識別符號將各個投影與用於更新的最新事件相關聯。非常適合用於診斷。

預設情況下，請使用自治的非同步投影。是的，它可能會增加UI的複雜性，以處理投影的最終一致性，但會開啟許多您需要針對效能進行優化的選項。使用適合目的的任何儲存機制，在需要時進行重建以及在多臺伺服器上擴充套件投影儀以達到一流的效能。如果您確實需要作為域更改的一部分來更新特定的投影儀，請考慮等待投影儀趕上該域釋出的最後一個事件。

請注意，在負載下，基於全域性檢查點對基於SQL的事件儲存進行排隊可能會導致您由於正在進行的事務而錯過事件。使用back-off視窗或序列化對每個分割槽的事件儲存進行寫操作來解決此問題。

通過讓投影機將自己標記為正在重建並將其進度顯示為ETA等，將重建投影視為特殊狀態。智慧投影儀還會檢測事件儲存是否已回滾到較早的狀態（由於資料庫還原或生產補丁程式），並將自動重建自身。

盡一切努力使重建迅速。使用積極的快取，使用NoSQL資料庫，在記憶體中並分批進行專案，然後寫入資料庫，如果對投影有意義，則通過Steam進行專案流，分批從事件儲存中讀取（並且對異常處理要精明） ，使用ORM並從其工作單元中受益，以減少SQL語句。您甚至可以停止與該投影機不再相關的聚合的投影事件，例如，通過將特定聚合（流）的所有事件都可以歸檔的後設資料新增到事件儲存中。

不要合併來自多個投影的資料，除非您知道考慮到每個投影機的真實性和非同步性，這是安全的。如果確實需要從其他聚合中捕獲資訊，請擁有投影的投影儀根據這些聚合的事件維護自己的私有查詢。另一個例外示例是您從事件中構建資料倉儲的情況，但是即使如此，您仍需要考慮一致性的權衡。

作為事件的測試單位，對整個投影機進行測試，並附帶事件，並以查詢結果或HTTP API作為輸出。將投影儀本身及其儲存投影的方式視為可隨時間變化的實現細節。在此處檢視如何以功能和可讀的方式構建此類測試的示例。