前言

ENode是一個應用開發框架，為開發人員提供了一整套基於DDD+CQRS+ES+EDA架構風格的解決方案。ENode從釋出1.0開始到現在的差不多兩年時間，我幾乎每週都在更新設計或實現程式碼。以至於從來沒有一個穩定的版本可以提供給大家，非常慚愧。但我相信，隨著時間的推移和我的努力的積累，ENode一定會越來越穩定和成熟的。我覺得我此刻很幸福，因為我有自己的興趣且有機會在業餘時間為了自己的興趣而奮鬥。

今天是個開心的日子，因為我終於使用ENode開發出了一個比較有說服力的真實案例，一個線上會議位置管理與訂購系統。該案例與微軟的Microfost CQRS Journey案例的功能一致，只是是用ENode開發完成的。目的是為了展示：

1. 如何使用ENode支援DDD領域層的實現；
2. 如何使用ENode實現CQRS+ES的架構；
3. 如何使用ENode實現事件驅動的架構（EDA）；

另外，在案例開發過程中，也不斷髮現了ENode, EQueue的很多問題。所以，通過做這個案例，也幫助ENode, EQueue完善了很多。真是要實踐才能進步啊！

ENode架構簡介

ENode目前的架構已經和最初的1.0版本有較大的差別了。比如，沒有了對Redis的依賴，增加了Command Store的設計。最新版本的ENode架構圖如下：

熟悉CQRS架構的人應該對這個圖不太陌生。需要強調的有兩點：

1. 新版的架構圖中，Domain Aggregate是常駐記憶體的；聚合根的職責就是封裝狀態、業務規則，同時產生領域事件；
2. 新增了一個Command Store，用於實現Command的冪等處理；

關於圖中的其他部分的介紹，請參看我之前寫的關於ENode系列的文章。 

ENode關鍵特性

1. 實現了CQRS架構，支援分散式，基於佇列的水平擴充套件，框架設計之初就考慮了架構的各個節點的水平擴充套件；

2. 面向高併發設計；架構層面，充分考慮到了如何解決併發問題；通過用EQueue實現伺服器之間的訊息路由、通過單機內部實現類似Actor Mailbox的設計，從而避免併發的產生。提高CQRS架構C端的整體寫入吞吐量；即便在某些極端情況下出現併發問題，也支援自動的樂觀檢測，並自動重試；另外，架構層面，規定一個command只能涉及一個聚合根的修改，從而規範應用開發者必須嚴格按照訊息驅動的思路來實現複雜的業務流程，而不能使用工作單元的方式，以事務的方式實現資料的強一致性；
3. 嚴謹的訊息冪等處理支援；由於ENode是訊息驅動的架構，所以對訊息的冪等性處理，是框架關注的一個重要的方面，並在架構層面做了支援。這使得應用開發人員不必擔心訊息的重複處理帶來的問題。
4. Domain Aggregate常駐記憶體；這個設計可以提高C端command的處理效能。因為我們不必像傳統的方式那樣先把聚合根從db取出來，再修改，再儲存回去了；
5. 框架為開發人員展示瞭如何更好的實現Sagas，在CQRS架構中，Sagas指基於訊息驅動的業務流程；一個Saga包含若干個聚合根以及一個（通常）流程管理器（Process Manager）；聚合根維護流程中的所有參與者物件的狀態以及流程本身的狀態，流程管理器負責定義和實現流程控制邏輯，無狀態；流程管理器的實現是通過響應事件、異常、應用層訊息，然後傳送相應的命令，從而實現訊息驅動的流程；
6. 採用Event Sourcing（簡稱ES）的方式來持久化聚合根狀態；通過ES實現聚合根狀態的還原以及通用的併發控制，通過聚合根ID+事件版本號作為唯一索引的思路實現樂觀併發控制；
7. 訊息除了command, domain event外，還支援exception message, application message；這兩種訊息是我們在遇到有些訊息不適合用domain event來表達時需要使用到；比如聚合裡有時我們要修改某個狀態前會先做業務規則的檢查判斷，如果不合法，通常會拋異常，然後這個異常我們又希望可以讓流程管理器知道，從而流程管理器可以做後面的回滾或補償措施；另外，我們有時可能會在應用層面（command handler裡）和其他外部系統發生互動，那互動的結果，使用應用層的訊息更合理；ENode在架構層面，對上面這些訊息做了統一的支援；
8. 框架提供返回單個command執行結果以及阻塞等待command執行結果的支援，這個對於開發者希望同步執行command並知道command執行結果的時候，非常有幫助；這樣開發者就不用自己去輪訓了。
9. 除了對訊息的冪等處理的支援外，ENode對domain event的順序處理，也做了充分的考慮和支援，確保當C端產生的domain event同步到Q端時，Q端處理時，框架層面能確保Q端的處理順序不會亂序。從而保證C,Q兩端的資料是最終一致的；
10. 保證訊息能至少被處理一次；主要思路是確保訊息的：1）持久化；2）訊息ACK後才認為已消費；
11. 支援一個聚合根一次可以產生多個domain event；雖然大部分情況，一個聚合根一次只會產生一個domain event，但有些場景，可能會產生兩個或多個。此時，這些事件會以一個事件流的方式一起apply到當前聚合根；同時，在Q端，框架也會通過必要的手段，與使用者程式碼一起保證了事件流中的事件的處理順序的正確性；
12. ENode所使用的分散式訊息佇列EQueue，參考了阿里的RocketMQ的架構思想，具有高效能、可擴充套件、輕量級的特性，支援不受限於機器記憶體大小的訊息堆積能力，而且是純C#開發。同時還提供了簡單實用的管理控制檯，可以讓我們輕鬆的管理訊息佇列。比如可以方便的動態增加、禁用、啟用、刪除佇列，查詢訊息內容、訊息消費進度，等資訊；目前，EQueue也已經經過多個迭代，並且已經有真實使用者進行使用，功能基本趨於成熟穩定。

Conference案例簡介

Conference是一個微軟開發的，基於DDD+CQRS+ES的一個開源專案。專案主頁：cqrsjourney.github.io

這個專案，對我們大家學習DDD領域驅動設計、CQRS+ES的架構，非常有幫助。

• 該案例從業務上，實現了一個典型的電子商務系統的關鍵環節：商品管理、庫存管理、下單、減庫存、支付；
• 該案例從技術上，很好的展示了CQRS架構的優點。比如可以在Q端定製不同的檢視，以應對不同的查詢需求；
• 該案例很好的向我們展示瞭如何劃分領域，劃分邊界上下文（bounded context），並如何使用不同的架構技術，實現不同的上下文，非常具有學習價值。

正是因為這個專案的以上優點，讓我有興趣使用ENode作為技術支撐，實現同樣功能的系統。在重寫的過程中，保留了所有非技術的東西，比如邊界上下文的劃分、領域層等；所有技術相關的部分，用ENode替代。

希望有興趣的同學，可以去下載原始碼進行研究。瞭解ENode，最快的方法就是從案例程式碼開始。如果想進行交流，可以加QQ群：185916873，隨時歡迎有興趣的道友加入。

最後，貼一個Conference案例中訂單處理的Sagas流程圖：

不早了，實在寫不下去了，就到這吧。