學習大綱
1、 三層職責
2.、引入領域驅動設計
3、何爲限界上下文
4、何爲領域
5、領域分層
6、實體和值對象
7、Service
8、生命週期之聚合
9、生命週期之Factory
10、生命週期之Repository
11、命名規範設計
12、貧血模型
13、領域服務
一、MVC模式
用一種業務邏輯、數據、界面顯示分離的方式
View。
負責與頁面的交互，現實數據的輸入和輸出
Model。
主要負責處理業務邏輯以及數據庫的交互。
Controller負責調度View層和Model層，主要接收請求，然後轉發到Model處理，處
理後返回視圖。
MVC的目的是將M和V的實現分離，實現Web系統的職能分工。
二、三層架構
1 、Dao層主要是對數據的基本操作，包含構造SQL、參數等。
2 、Service層負責領域業務的處理，負責邏輯處理及轉換。對流入的邏輯性數據的
正確性及有效性負責，對流出的邏輯性數據及用戶性數據不負責。
3 、Web層不承擔任何業務邏輯，主要做於業務無關的操作和邏輯的編排優點。
優點
1 、降低層與層之間的依賴。
2 、達到各層複用的目的。
缺點
1 、拉長了行爲的鏈路，降低了性能。
2 、新增功能時需要在每層變動，增加了開發成本。
三、兩者的區別
MVC模式的目的是實現Web系統的職能分工，即職責劃分
三層架構的目的着重點是“高內聚，低耦合”
先有架構設計，再使用設計模式
四、阿里規約
開放接口層：可直接封裝 Service 方法暴露成 RPC 接口;通過 Web 封
裝成 http 接口;進行 網關安全控制、流量控制等。
Web 層：主要是對訪問控制進行轉發，各類基本參數校驗、異常處理
等。
Service 層：相對具體的業務邏輯服務層。
Manager 層：通用業務處理層，它有如下特徵:
1 、對第三方平臺封裝的層，預處理返回結果及轉化異常信息。
2 、對Service層通用能力的下沉。
3 、與DAO層交互，對多個DAO的組合複用。
DAO 層：數據訪問層，與底層 MySQL、Oracle、Hbase 進行數據交互。
五、出現的問題
Web層的邏輯比Service層還多，各層職責越界了。
Entity/Map/JSON對象透傳所有層。
六、明確規範
應用層
用於接收外部的請求，是整個系統所提供能力的入口。專用於處理與業務無
關的操作，包含驗籤、參數校驗、攔截等處理，通過編排業務領域和外部請
求，對外提供細粒度的能力。
業務領域層
業務領域層主要用於實現業務邏輯，包含業務規則、策略和流程。
基礎設施層
基礎設施層爲以上各層提供技術支持，例如持久化操作、公用的操作等六、分層模型轉換。
分層的目的是爲了明確職責，每層就會有各自的數據模型。
1 、Request、Response對象只能出現在應用層。
2 、Request‐‐>Model、Model‐‐>Response都在應用層處理。
3 、Model‐‐>Entity、Entity‐‐>Model都在業務層中的倉儲層。
七、分層模型轉換
分層的目的是爲了明確職責，每層就會有各自的數據模型。
1、Request、Response對象只能出現在應用層。
2、Request‐‐>Model、Model‐‐>Response都在應用層處理。
3、Model‐‐>Entity、Entity‐‐>Model都在業務層中的倉儲層。