在一些微服務的規劃中，微服務類似將單體系統切割成多個高內聚的獨立模組，且服務與服務間鬆耦合。

假設在單體系統，改了某個業務邏輯與相關的程式，卻於另外一個功能模組出現錯誤，如此就是系統邏輯模塊間高度相依的下場。

如果是核心系統，就需要分析出哪幾塊是可以被切分出來。這其實非常有挑戰性與前瞻性，要將什麼切出來、獨立出來後未來擴充也不會造成相依性過高，其實非常不容易，議題可能也是大哉問。

這對有歷史包袱的企業也是非常大的挑戰，除非經營者願意且有預算將整個系統做重構規劃。
如果有預算則是實行目前較多企業希望導入的微服務架構，或者朝SOA建構的計劃，將業務邏輯解耦並以API或web服務的方式溝通。如果資訊部門想在更進一步提升公司整體E化運作效率與價值，導入更多共享生態圈所需的加值服務，解耦的系統是更快更容易達成的。

假設以初淺的舉例，一家公司有會計、法務、出納、人資、業績規劃、流程規劃...再加上domain相關之單位等等等... "初步" 應該可以依照各單位工作內容切割成服務模組。

而每個模組可能會共用一些組件，這些組件再獨立出來成為一個微服務...如此在更新上線時是較好管理的，較容易整合測試。

模擬一個狀況，業務收到客戶同意接洽生意，業務準備要撥款給客戶，所以業務人員發出撥款申請需求。
這個需求由API打進系統，會先於中介服務層做routing與arrange，於是會安排抓domain業務模組、流程規劃模組、會計算帳模組、出納模組、業績模組、法務模組是否合法等等，幾乎都會牽扯到。

資料庫操作亦是一個問題，因為數多的業務操作，對資料庫是個負擔，資料庫會越來越累(頓)，效能就會是個嚴重的問題。而CQRS似乎在某些情境提升效能。如統計報告、月報、年報半年報等。

(引用微軟的圖)

(引用微軟的圖)

但如果不要使用CQRS，去掉"CQ" 只要達成 Responsibility Segregation ，那就是看如何切割解耦。

(引用微軟的圖)

而無論實行 CQRS 或 只要 "RS" 皆可安排 MediatR 與 Event-Driven 方式來協助；
利用 MediatR 做分離目的來達成 CQRS，QUEUE 可以當作 event-driven 來實行。

(引用微軟的圖)

相關套件也可以讓專案更趨近於簡潔化，而將解耦的服務再加上這些對應機制的套件也可來達成某些情境的效能提升。
所以接下來將會看到 MediatR 的探討，與 Event-Driven 可由 QUEUE 模擬的探討。

參考連結:
https://martinfowler.com/articles/microservices.html

https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation

https://docs.microsoft.com/zh-tw/dotnet/architecture/microservices/multi-container-microservice-net-applications/rabbitmq-event-bus-development-test-environment

https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/