今天主要簡單介紹下DDD結合CQRS架構實現的這麼一個營銷服務，這個項目是公司項目，目前是我一個人在做，可能有些東西不便多說，希望理解吧。介紹分三部分，首先簡單說下概念（因爲我也不知道多少），然後說下實際應用情況，最後簡單說下實現。
DDD領域驅動設計，很高大上的一套方法論，比如領域專家，夠高大上吧，其實也未必要那麼專業，產品和業務能力強的開發人員也是可以的。我的理解它其實就是一套設計方法論，而且這套方法論有一定的門檻，概念多，業務強，業務架構能力也要好，同時需要團隊整體實力。DDD這幾年火的一塌糊塗，火是有原因的啊，因爲微服務，可能這句話說的有些片面，我的理解就是這樣的。簡單來說微服務是架構，但是它並沒有給出如何對複雜系統進行拆分的具體方法論，而DDD剛好就是指導微服務架構落地的這麼一個具體的解決方案，可以這麼說，沒有DDD方法論的指導，微服務是肯定很難落地的。那可能有人會說，我不做微服務架構，就沒必要採用DDD設計了？當然不是，即便你是單體架構，利用DDD方案，只要合理，複雜系統也會簡單化、模塊化，這麼說吧，DDD這個指導方法論，大到領域邊界劃分，小到聚合單元劃分，代碼既設計，工程既設計，方案既設計，領域既設計，如果後期想做微服務架構遷移，也能很輕鬆的落地。
CQRS，命令查詢職責分離，簡單來說就是讀寫分離（核心就是消息），這個分離分兩個維度，代碼級別和數據級別的分離，命令和查詢模型分離，僅此而已，一切只是爲了設計更簡單、單一而已，同時它也引出了諸多問題，如一致性問題、冪等性問題，事務問題等。對於CQRS命令消息我這邊的實現比較簡單，基於MediatR實現的消息管道分發，數據庫也未做讀寫分離，只是做了模型分離，相對來說是一個極簡的CQRS架構，如果要實現一套穩定成熟的框架，需要一定的技術支撐，CQRS只是架構，它並不是框架，目前我瞭解到的好像.NET是沒有成熟的框架（我也沒怎麼關注）。
實現，下面這張圖是我目前做完的一個營銷服務，本身業務也比較簡單，公司項目不便多說，簡單說下技術實現吧![]()
基於.NET5.0，DDD VS 極簡CQRS架構實現，整個解決方案簡單分了四層，參考DDD分層設計。Service層其實就是api接口層，很輕薄的一層，沒有任何業務邏輯，App層我這裏實現的比較重，包括業務聚合和實現，Infrastructure基礎設施層，倉儲實現在這一層。這裏簡單介紹下Domain層吧，因爲它是比較核心的一層吧，領域層包括領域事件、領域模型和領域相關的基礎類庫。模型層包含了一些聚合，聚合之間通過聚合根id關聯，一個聚合根對應一個respository倉儲，並且擁有領域事件的分發能力。內部聚合採用強一致性策略，也就是說聚合根控制着整個聚合的不變性和事務一致性，外部聚合採用最終一致性策略，這個主要是考慮性能問題，死鎖問題，同時在多聚合一致性上又做了一些額外的設計，主要是確保核心域的數據強一致性。併發控制，因爲我這邊有個特需的業務需求，庫存的問題，我這邊採用的是樂觀鎖結合降級策略實現，Domain層大概就是這些東西，我這邊主要是給需要做DDDvsCQRS落地的一些參考，不要糾結，什麼樣的需求就會設計什麼樣的方案。
模型分離，主要是命令和查詢模型分離，命令關注的是增刪改，它會修改模型狀態，查詢是單獨的一套模型，這樣在代碼層面也做了分離。我這邊命令實現是基於MediatR管道實現，同時也做了冪等性處理，命令校驗部分基於FluentValidation庫實現，並納入Behavior管道處理，持久化ORM基於EFCORE5.0。查詢相對來說比較簡單，基於Dapper實現。
事件，我這邊主要實現的有領域事件和集成事件，領域事件主要解決的是領域模型狀態的變更，解耦聚合之間的業務，同樣基於MediatR管道實現。集成事件主要解決的是微服務各子系統之間完整業務的變更，解耦微服務之間的業務，集成事件主要是自己實現的一個極簡的事件總線。
順便提一下，前兩天同事問的一個問題，異常提醒持久化方案，我簡單說下我這邊的處理方案吧，我把異常分爲三個類型，面向用戶的異常、領域模型異常、系統異常。面向用戶的異常，一般爲校驗類的，這種主要是面向用戶提醒的，不記錄日誌。領域模型異常，此類異常一般情況爲領域業務異常，記錄日誌。最後一種系統異常，也就是未知異常了，統一提醒爲系統異常並記錄日誌。怎麼統一處理？在.NETCORE框架裏面有兩種方案，基於篩選器、或者中間件都可以，還可以完美結合資源篩選器實現多語言功能。
好了大概就這麼多吧，因爲是公司項目，具體細節不便多說，明天還的上班，就這樣吧。