pop----oop-----aop---ddd
描述：考慮問題是1234步驟
特點：簡單，無法應對複雜需求
舉例子：把食物放冰箱
第一步：開啟冰箱
第二步：塞進去食物
第三步：關冰箱
特點：把事物作為物件考慮
特性：封裝、繼承、多型
描述：物件互動，完成功能
缺點：編譯時確定，執行時確定，不方便擴充套件
描述：既不修改類，又能擴充套件功能
好處：1.關注核心邏輯，aop擴充套件公共邏輯
2.**復用，集中管理，方便 維護公升級
應用場景：1.asp.net.core--filter
2.autofac的aop擴充套件
ddd領域驅動是什麼？
domain-driven-design
解決的問題：系統規模日益變大，為了方便擴充套件，劃分出更大的盒子
描述：乙個系統都是為了解決乙個問題，可以把總的系統看成乙個大盒子，然後把乙個大盒子拆分成幾個子系統，子系統叫做領域
特點：拆分作用域以後，會有統一語言
例子：部落格有發帖，回帖，使用者，積分，可以把這四個功能看成四個領域，發帖，回帖，使用者，積分
描述：基於驅動領域設計，以目標為導向，為領域做設計
特點：完成領域需求，程式分析時，不考慮實現
描述：領域是核心，先確定共同的領域，資料庫設計，**設計
與傳統開發對比：1.開發和需求統一規範不同
2.容易需求變更，需求分析不夠
3.傳統系統步驟：分析--資料庫設計--流程，一旦發生業務改變，整個系統變動特別大
畫盒子-----拆領域
包含內容： 1.資料操作 2.資料儲存 3.常用幫助類 4.資料驗證
描述：最核心重要的，體系架構都是基於領域驅動的
包含內容：資料、業務、工廠、倉儲
領域約束：聚合跟（agregateroot）
倉儲：資料固化，運算元據庫
倉儲操作聚合根
描述：請求**，跨領域問題，這裡不包含任何領域邏輯
描述：用來頁面展示
包含：dto(為需要的字段做最小原子化，需要那些欄位就展示那些字段)
貧血模型：沒有任何邏輯
完成互動，專門為ui服務
pop----oop-----aop---ddd
描述：考慮問題是1234步驟
特點：簡單，無法應對複雜需求
舉例子：把食物放冰箱
第一步：開啟冰箱
第二步：塞進去食物
第三步：關冰箱
特點：把事物作為物件考慮
特性：封裝、繼承、多型
描述：物件互動，完成功能
缺點：編譯時確定，執行時確定，不方便擴充套件
描述：既不修改類，又能擴充套件功能
好處：1.關注核心邏輯，aop擴充套件公共邏輯
2.**復用，集中管理，方便 維護公升級
應用場景：1.asp.net.core--filter
2.autofac的aop擴充套件
ddd領域驅動是什麼？
domain-driven-design
解決的問題：系統規模日益變大，為了方便擴充套件，劃分出更大的盒子
描述：乙個系統都是為了解決乙個問題，可以把總的系統看成乙個大盒子，然後把乙個大盒子拆分成幾個子系統，子系統叫做領域
特點：拆分作用域以後，會有統一語言
例子：部落格有發帖，回帖，使用者，積分，可以把這四個功能看成四個領域，發帖，回帖，使用者，積分
描述：基於驅動領域設計，以目標為導向，為領域做設計
特點：完成領域需求，程式分析時，不考慮實現
描述：領域是核心，先確定共同的領域，資料庫設計，**設計
與傳統開發對比：1.開發和需求統一規範不同
2.容易需求變更，需求分析不夠
3.傳統系統步驟：分析--資料庫設計--流程，一旦發生業務改變，整個系統變動特別大
畫盒子-----拆領域
包含內容： 1.資料操作 2.資料儲存 3.常用幫助類 4.資料驗證
描述：最核心重要的，體系架構都是基於領域驅動的
包含內容：資料、業務、工廠、倉儲
領域約束：聚合跟（agregateroot）
倉儲：資料固化，運算元據庫
倉儲操作聚合根
描述：請求**，跨領域問題，這裡不包含任何領域邏輯
描述：用來頁面展示
包含：dto(為需要的字段做最小原子化，需要那些欄位就展示那些字段)
貧血模型：沒有任何邏輯
完成互動，專門為ui服務
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd？1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...