我們如何從DDD中受益？ 第三部分
摘要：
DDD最大的挑戰絕對是戰略設計部分，即如何劃分有界上下文正確和構建領域模型。
很難用語言表達清楚，我認為最好的方法是更多練習，並從大師那裡學到更多東西，例如，嘗試Event Storming。
之後，如果團隊沒有任何領域驅動開發經驗，請不要低估技術部分的挑戰。和很多人說技術部分不那麼重...
DDD最大的挑戰絕對是戰略設計部分，即如何劃分有界上下文正確和構建領域模型。
很難用語言表達清楚，我認為最好的方法是更多練習，並從大師那裡學到更多東西，例如，嘗試Event Storming。
之後，如果團隊沒有任何領域驅動開發經驗，請不要低估技術部分的挑戰。和很多人說技術部分不那麼重要不同，如果沒有以適當的方式實施，領域驅動很難真正理解。我們在練習時遇到了一些典型的問題，幸運的是，我們很好地解決了這些問題。
- 開發人員認為Event Sourcing並不重要，例如，在之前案例情況下，您只需要在釋出Job時更改屬性Job.Status =“Published”，但現在需要定義了JobPublishedEvent。有時，一個更改需要定義很多事件，例如CompanyNameChangedEvent，CompanyEmployeeAddeedEvent。最重要的是，如何定義事件的粒度？
- 由於系統被劃分為大量基於有界上下文的子系統，系統之間的互動更加複雜。通過在以前的情況下在同一個MVC控制器Action中呼叫不同儲存庫的方式更改資料在此處不可用。
- 由於在使用CQRS進行查詢時需要單獨儲存QueryModel，因此與傳統的資料庫驅動開發相比，在同一資料庫中的寫入和讀取更復雜。
- 事件的版本管理，例如事件的更改，刪除和增加都需要考慮事件重放和域模型引起的影響。
- CQRS如何保證資料的及時性和一致性？例如，我在公司詳細資訊頁面中更改了公司名稱，然後單擊了儲存按鈕以導航到公司列表頁面，QueryModel可能仍未更新。
領域驅動設計如何使我們和我們的客戶受益
- 做正確的事：Domain Expert和團隊之間的高效通訊保證了正確反映業務規則的模型的設定。由於開發人員擁有可以直接使用的程式碼，以及因Domain而生成資料和行為，因此進行單元測試非常方便，因為Domain不依賴於第三方資料儲存，這可確保業務的實施。
- 它大大提高了通訊效率。我們都知道，一張圖表說的不止一千字。至於開發人員，他們真正需要的是“少說話，給我看程式碼！”。程式碼不僅更容易讓開發人員閱讀，而程式碼（Domain Object）也是最新的要求，即執行要求。
- 它大大提高了為專案新增新資源的效率。當一個新資源被新增到專案中時，它主要需要檢查域模型和測試域模型，然後您將通過此過程瞭解系統的幾乎所有業務規則。
- Domain-Driven的技術部分為新增新功能或擴充套件系統帶來了極大的便利。我在這裡舉幾個例子：
- 由於使用了事件源，我們很容易檢查歷史資料，也就是說，我們只需要分配一個時間點，然後我們只需要在我們做事件重播時重播到這個時間點。
- 操作日誌：以前，如果我們想要記錄操作日誌，會有整個程式碼的日誌，但是現在我們只需要重放事件，然後你可以檢查你想要檢視的任何日誌，它可以通過重放事件流簡單地實現資料庫儲存。
- 系統通訊：通過事件釋出可以實現通訊，其他系統只需要訂閱我們的事件，我們的系統和其他系統之間沒有直接的依賴關係。
- 它大大提高了向系統新增新功能的便利性，在大多數情況下，它只是新增新功能時的事件訂閱。
- 即 CQRS和Query模型大大提高了系統的查詢效能。當我需要一個新介面時，我不需要對寫入端進行任何修改，包括類檔案。是否與關閉修改和開放擴充套件（OCP）的規則非常一致？我們只需要構建類似於新的EventHandler並重播相應事件的東西。
- 由於使用了事件源，系統之間的事件整合（如訊息佇列釋出和事件訂閱）可以大大提高系統壓縮能力。我們可以將事件放在佇列中，因此如果以後沒有及時處理系統處理，它不會導致前端系統崩潰。
- 系統性能大大提高。寫入端只有插入操作，沒有修改操作; 並且在讀取端只有讀操作。結果，可以大大減輕輸出儲存和讀取的瓶頸。
其他好處：
- 開發人員可以更專注於解決業務問題。由於一切都是事件，開發人員可以在基本庫實現後忽略資料儲存，並將大部分時間花在編寫業務程式碼上。如果不關心如何儲存資料，那麼資料儲存只有兩個操作：AggregateRoot.Get（ID），AggregateRoot.Save（）
- EventPublish.Pubish（CompanyNameChangedEvent）然後事件訂閱者只需要新增一個EventHandler。
- 系統很好地解耦，業務邏輯集中在領域中，不同於以前在許多地方存在業務邏輯的情況，現在您在修改某些功能時不需要太擔心。
- 不需要過多擔心開發人員，特別是由初級開發人員編寫的遍佈整個系統的錯誤程式碼導致的對其他功能的影響將大大降低。稽核程式碼實際上是稽核業務實現的單元類，因此不需要過多擔心技術實現引起的不正確部分，因為開發成本可以通過基本庫的適當平衡來減少團隊成員寫得很好。
- 最後，更容易做出更改和新增新功能的好處，完全支援敏捷哲學的“擁抱變化”，是不是？
領域驅動設計有許多好處，許多概念，相對有較高的障礙和對人員有高要求。至少應該有團隊中的領導者，否則，成本會很高，尤其要小心使用事件溯源。Domain-Driven特別適合那些業務相對複雜的專案，對於那些小專案，CRUD仍然是一個不錯的選擇。