400-626-7377
400-626-7377
領域驅動設計（DDD）是由Eric Evans提出的一種軟件開發方法，其核心思想是將業務領域的核心概念、規則和流程作為軟件設計的核心驅動力。通過深入了解業務領域，開發人員能夠設計出更符合業務需求的軟件系統，提高系統的可用性和可維護性。
DDD強調與業務專家緊密合作，共同建立領域模型，使軟件設計能夠準確反映業務領域的實際情況。領域模型是DDD的核心，它是對業務領域的抽象和表示，有助于開發人員深入理解業務領域，從而設計出更優質的軟件系統。
DDD更加關注業務邏輯和領域模型的建模和實現，旨在解決復雜業務問題
MVC更加關注如何將應用程序分層，以便于管理和維護
DDD適用于復雜的業務領域，需要深入理解業務邏輯和領域模型的場景
MVC適用于對用戶界面和數據交互進行有效管理的場景，如Web應用程序和桌面應用程序等
DDD通常以領域模型為核心，通過聚合、實體、值對象等概念進行組織和建模
MVC通過模型、視圖、控制器的分離來組織應用程序，以實現更好的可維護性和可擴展性
DDD強調領域專家與開發團隊之間的密切合作，通過溝通和協作來不斷迭代和優化領域模型
MVC更加注重開發人員之間的分工合作，各個部分之間通過界面或接口進行通信
通過與業務專家緊密合作，開發團隊可以更好地理解業務需求和業務流程
使用DDD可以創建更加靈活和可維護的代碼，因為模型更好地反映了業務邏輯
DDD鼓勵劃分限界上下文，使得系統能夠更好地應對變化
通過使用統一語言和明確的領域模型，開發人員能夠更快地理解和實現業務需求
DDD的方法論可以幫助開發人員更好地把握業務核心，設計出更符合業務需求的系統架構
在DDD中，設計過程是自頂向下的，以業務為主導。幫助開發人員能夠站在更高的視角，從業務需求出發，來規劃和設計系統架構
對于涉及多個業務領域、具有復雜業務流程的大型系統，DDD能夠幫助開發人員建立清晰的領域模型，提高系統的可維護性和可擴展性
DDD通過強調業務領域和軟件設計的緊密聯系，使得開發團隊能夠更快地理解業務需求，并快速調整軟件系統以支持新的業務需求
剖析軟件退化的根源，指明解決問題的方向
剖析DDD的設計思想
實踐DDD的4大難題及真正作用
通過DDD來應對復雜系統的需求變更，實現高質量的軟件設計，避免代碼腐化
講解DDD是如何解決軟件退化等問題，為學員能夠有效提高軟件設計質量，提供了思路與方向
通過真實案例來一步一步講解如何進行領域驅動設計
講解如何通過領域驅動設計來指導軟件變更，實現高質量的軟件設計
通過大量真實的案例，講解許多公司在開展領域驅動設計的過程中面臨的難題、解決的思路以及最終的設計思想
獲得由工業和信息化部教育與考試中心統一頒發
《領域驅動軟件設計工程師認證》
案例：演示電商網站付款功能代碼質量下降的過程
案例分析：揭示軟件退化的根源
案例：演示嵌入式溫控系統越來越難于維護的根源
案例分析：領域分析才是解決之道
案例：重新演練電商網站付款功能的變更過程
演練案例：在線訂餐系統的領域設計過程
分組練習：按照事件風暴的步驟進行業務領域建模
實戰演練：遠程智慧醫療大數據平臺設計過程
分組練習：按照領域模型進行設計開發
案例：在線訂餐系統的應用
實戰演練：高并發高可用的訂單系統
案例：電商網站購物功能的設計
案例：電商網站下單服務的設計
案例：電商網站多渠道支付的微服務實現
案例：大數據與微服務結合的架構設計
案例：電商網站海量訂單數據的秒級查詢
案例：電商網站異步化操作的微服務實現
為什么我們需要領域驅動設計
1.現如今DDD越來越流行
2.DDD并不能幫助新項目的軟件開發
3.DDD真正的作用是日后長期的維護
實踐DDD的4大難題：
1.準確理解為什么要采用DDD？
2.怎樣正確地進行業務領域建模？
3.怎樣用領域模型指導開發與變更？
4.如何設計支持領域驅動的架構設計？
DDD真正的作用是應對日后的軟件維護
1.我們現在面對的是快速變化的時代
2.變更越頻繁，代碼質量下降越快
案例：演示電商網站付款功能代碼質量下降的過程
案例分析：揭示軟件退化的根源
DDD的解決之道：業務領域建模
3.系統規模越來越大，系統越來越復雜
案例：演示嵌入式溫控系統越來越難于維護的根源
案例分析：領域分析才是解決之道
DDD的解決之道：基于限界上下文拆分系統
案例分析：演示電商網站付款功能代碼質量下降的過程
1.起初的設計
2.隨后的變更
3.質量不斷下降的過程
軟件質量下降的根源：
1.軟件總是因變更而變得越來越復雜
2.軟件結構已經不再適應復雜的軟件需求
3.必須要調整軟件結構以適應新的軟件需求
DDD的建模過程：
1.每次需求變更時先對需求進行領域分析
2.基于領域分析先進行領域模型的變更
3.基于領域模型的變更去指導程序的變更
DDD是應對軟件復雜性之道
1.剖析領域驅動的設計思想
2.服務、實體與值對象的概念
3.充血模型與貧血模型的設計思路
4.問題域、子域與限界上下文劃分
基于領域模型的設計變更
1.演練基于DDD的設計與變更過程
2.演練領域模型如何指導數據庫設計
3.演練領域模型如何指導程序設計
4.聚合、倉庫與工廠：傻傻分不清
5.限界上下文：系統拆分的利器
案例：重新演練電商網站付款功能的變更過程
第一個版本的領域模型與設計
第一次變更的分析設計過程
第二場變更的設計實現
第三次變更的設計實現
第四次變更與架構演化
領域建模分析過程
演練案例：在線訂餐系統的領域設計過程
1.從領域中吸取知識
2.統一語言建模
3.事件風暴會議
1）梳理業務流程，識別領域事件
2）為每個領域事件識別參與者、行為、相關事物
3）標記事物之間的關系、聚合、聚合根
4）根據業務劃分限界上下文
5）遍歷所有事件，確定上下文映射
4.業務領域建模
1）為每個領域事件構建業務領域模型
2）劃分主題域、支撐域、通用域
3）落實各子域之間的聯系、接口及事件通知機制
基于領域模型的微服務設計
1.小而專的微服務設計
2.限界上下文與微服務拆分
3.上下文地圖與微服務接口
4.各微服務中實體、值對象與服務的設計
5.各微服務中聚合、工廠與倉庫的設計
6.領域模型4種關系3種繼承的數據庫設計
7.聚合層的設計、工廠和倉庫的實現
8.基于DDD的微服務架構分層
解決DDD的設計難題
1.跨庫查詢的設計難題與設計實現
2.領域事件的通知機制與設計實現
3.微服務接口的防腐層設計
4.狀態查詢跟蹤的設計思路與代碼實現
分組練習：按照事件風暴的步驟進行業務領域建模
1. 召開事件風暴會議
2. 進行業務領域建模
3. 基于領域模型設計開發系統
實戰演練：遠程智慧醫療大數據平臺設計過程
1.系統業務規劃與戰略設計
2.子系統→限界上下文→功能模塊劃分
3.由粗到細的用例建模
4.各子域業務領域建模
1）智慧診療數據模型的領域分析
2）診所管理信息系統的領域分析
5.各子域的接口設計
1）上下文地圖的模型分析
2）微服務接口的方案設計
6.微服務的技術落地實踐
1）去中心化的技術治理
2）微服務的技術中臺
3）微服務的云端應用平臺
起初：一個傳統的診所管理系統向互聯網轉型
1）起初沒有采用領域驅動設計，也運行了這么多年
2）現在向互聯網轉型，業務變得越來越復雜，怎么開始領域建模？
第一步：站在全局的系統建設規劃
第二步：DDD戰略設計與限界上下文劃分
第三步：各子域的業務領域建模
第四步：上下文地圖與各子域的接口設計
轉型成互聯網連鎖診所系統，又該如何分析設計
1）基于領域模型進行新需求的分析
2）基于領域模型進行原有代碼的更新維護
3）基于限界上下文進行微服務的拆分，以及這個過程中的坑
第一步：基于DDD進行戰略設計的調整
第二步：各子域的業務領域建模調整
第四步：上下文地圖與各子域的接口設計
第五步：基于DDD的微服務拆分
?基于DDD的數據庫設計與去中心化的數據治理
?如何由原有的貧血模型向現在的充血模型改造
?如何解決跨庫的關聯查詢與事務處理
?如何實現領域事件的消息推送機制
?如何實現跨庫的狀態數據查詢
?如何打造基于整潔架構的領域驅動設計框架
增加人工智能的智能診療數據模型
1）如何通過領域模型來開展數據智能業務
2）如何基于領域模型的規劃與智能系統的接口
3）基于領域模型的微服務+大數據的設計實踐
分組練習：按照領域模型進行設計開發
1. 基于領域模型進行微服務的拆分與設計
2. 基于領域模型進行每個微服務的數據庫設計
3. 基于上下文地圖形成微服務間的契約與接口
DDD需要強大技術架構支持
1.降低技術門檻，減少開發工作量 → 制訂規范、合理分層、降低復雜度
2.易于業務變更，易于架構演化 → 將業務與技術解耦
3.支持領域驅動，支持微服務 → 通用倉庫、工廠及基礎設施的設計
4.平臺不斷完善，功能不斷積累 → 敏捷架構設計：架構跑道與使能故事
支持DDD的技術架構建設思路
1.分析當前軟件架構設計與架構演化的痛點與根源
2.闡述技術中臺的建設思路
1）將業務與技術解耦 → 整潔架構與六邊形架構
2）提取共性，精簡業務代碼 → 單Controller，單Dao
支持領域驅動+微服務的技術中臺
案例：在線訂餐系統的應用
1.通用、可配置的DDD倉庫與工廠的設計
2.解決跨庫的關聯查詢與事務處理
3.純潔的Service與Entity便于不斷地架構演化
現有系統的整潔架構轉型
1.系統級的重構方法與步驟
2.建立接口層解耦業務代碼與技術框架的過程
3.基于整潔架構的技術架構演化與快速交付
實戰演練：高并發高可用的訂單系統
微服務架構的6種設計模式
1.聚合模式
案例：電商網站購物功能的設計
?微服務前后端分離的設計
?分布式事務的兩階段提交
?TCC方案與阿里Seata
演練：運用Seata實現微服務的分布式事務
?基于消息的最終一致性設計
演練：基于消息實現微服務的分布式事務
案例：電商網站下單服務的設計
單一職責原則與領域驅動設計
?互聯網縱向切分在微服務的實現
?縱向切分應當注意的設計問題
?解決跨庫關聯查詢的設計
演練：微服務間解決跨庫關聯查詢的設計
2.代理模式
案例：電商網站多渠道支付的微服務實現
3.鏈式模式
4.分支模式
5.數據共享模式
案例：大數據與微服務結合的架構設計
案例：電商網站海量訂單數據的秒級查詢
6.異步消息模式
案例：電商網站異步化操作的微服務實現
微服務的拆分原則
1.能不拆盡量不拆：減少微服務間的調用
2.該拆分就得拆分
1）公共模塊該拆分就得拆分
2）越來越復雜的模塊該拆分就得拆分