帶著問題去思考，大家好！ 前幾天瞭解到EF Core的開發模式：DB First（資料庫優先）,Model First（模式優先），Code First（代碼優先）。 我所接觸的大多是DB First。如果大家瞭解的話，有些開源後臺項目，基本都會有後兩者，因為方便大家更快的去使用部署起來後臺。 在建 ...
帶著問題去思考，大家好！
前幾天瞭解到EF Core的開發模式：DB First（資料庫優先）,Model First（模式優先），Code First（代碼優先）。
我所接觸的大多是DB First。如果大家瞭解的話，有些開源後臺項目，基本都會有後兩者，因為方便大家更快的去使用部署起來後臺。
在建議的Layered ['leɪəd] Architecture [ˈɑːrkɪtektʃər]模式中,---表示層，業務層和數據層，其後Evans分析並引入兩個關鍵變化。
一：將關註點放到layer上，而不是tier。layer是應用程式組件之間的邏輯分隔,而tier是物理上不同的應用程式和伺服器。
二：識別的層數分為4各層-表示層-應用層-領域層和基礎結構層
整體式應用程式
自底向下設計，我們都是圍繞著數據模型來進行開發設計，其中的過程以及尤其依賴數據模型的用戶界面和體驗。
在整體式應用程式中，數據從底部的持久化存儲到前端，然後在返回。
根據分層架構，我們都知道，從存儲到前端以及從前端到存儲。我們不應該考慮把應用程式堆棧分成兩部分嗎？獨立處理命令堆棧和讀堆棧對於開發是不是更加有效果呢？所以NOSql存儲來了，使得經典的RDBMS系統開始支持XML和JSON。這也正式Command and Query Responsibility Segregation(CQRS)模式的使用。
以上是結合CQRS設計的分層架構模式
CQRS方法
CQRS不是萬能的，重要的是他的思想。
有經驗的開發人員知道。創建一個理想的數據模型，使其能夠將關係數據模型的原則和最終用戶實際需要的視圖的複雜性結合起來是很困難的。如果只有一個應用程式堆棧，就只能有一個面向持久化的數據模型，但是需要調整這個模型，使其能夠有效的滿足前端的需求。特別是與某種方法學（如領域驅動設計的額外的抽象層結合起來時）,後端（業務邏輯和數據訪問邏輯）的設計很容易變得一團亂。
以上問題。CORS通過將設計問題分解為兩個較小的問題，新應用程式架構設計解決問題，並不釋施加外部約束，使設計變得更加簡單。具有不同的堆棧的好處是，容易為實現名利和查詢使用不同的對象模型。有必要，可以為命令使用一個完整的領域模型，為表示使用一個定製的普通的數據傳輸對象，可能這些對象從SQL查詢具體化的，需要多個表示前端，只需要額外創建讀模型。整體複雜度是個體複雜度的和，而不是笛卡爾積。
1：不同的資料庫
分解成不同的堆棧有一些問題,兩個堆棧同步問題，數據命令寫入能夠被一致地讀回？根據自身業務，CQRS實現可以基於一種兩種資料庫，如果使用一個共用資料庫，共用資料庫確保了經典的ACID一致性，只需要在讀堆棧中的普通查詢做一些額外的工作。
性能和擴展行，可以考慮為命令堆棧和讀堆棧使用不同的持久化端點。
什麼時候用CQRS？
這是一種模式，CQRS架構模式主要是被設計來解決高併發業務場景的性能問題。
基礎結構層的構成
基礎結構層是與使用具體的技術相關的所有東西，包括數據持久化O/RM框架（EF），外部的Web服務，特定的安全API，日誌記錄，跟蹤，IOC容器，緩存等。最突出的是組件的持久化層，也就是數據訪問層。
持久化層 緩存層 外部服務這些已經非常成熟，不在這裡贅述。
