溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“DDD建模六個問題與步驟是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“DDD建模六個問題與步驟是什么”吧！
DDD方法論的核心是將問題不斷分解，把大問題分解為小問題，大業務分解小領域，簡而言之就是分而治之，各個擊破。
分而治之是指直接面對大業務我們無從下手，需要按照一定方法進行分解，分解為高內聚的小領域，使得業務有邊界清晰，而這些小領域是我們有能力處理的，這就是領域驅動設計的核心。
各個擊破是指當問題被拆分為小領域后，因為小領域業務內聚，其子領域高度相關，我們在技術維度可以對其進行詳細設計，在管理維度可以按照領域對項目進行分工。需要指出DDD不能替代詳細設計，DDD是為了更清晰地進詳細設計。
在微服務流行的互聯網行業，當業務逐漸復雜時，技術人員需要解決如何劃分微服務邊界的問題，DDD這種清晰化業務邊界的特性正好可以用來解決這個問題。
我們的目標是將業務劃分清晰的邊界，而DDD是達成目標的有效方法之一，這一點是需要格外注意的。DDD是方法不是目標，不需要為了使用而使用。例如業務模型比較簡單可以很容易分析的業務就不需要使用DDD，還有一些目標是快速驗證類型的項目，追求短平快，前期可能也不需要使用領域驅動設計。
領域可以劃分多個子領域，子域可以再劃分多個子子域，限界上下文本質上也是一種子子域，那么在業務分解時一個業務模塊到底是領域、子域還是子子域？
我認為不用糾結在這個問題，因為這取決于看待這個模塊的角度。你認為整體可能是別人的局部，你認為的局部可能是別人的整體，叫什么名字不重要，最重要的是按照高內聚的原則將業務高度相關的模塊收斂在一起。
業務劃分粒度的粗細并沒有統一的標準，還是要根據業務需要、開發資源、技術實力等因素綜合考量。例如微服務拆分過細反而會增加開發、部署和維護的復雜度，但是拆分過粗可能會導致大量業務高度耦合，開發部署起來是挺快的，但是缺失可維護性和可擴展性，這需要根據實際情況做出權衡。
領域對象與數據對象一個重要的區別是值對象存儲方式。在討論領域對象和數據對象之前，我們首先討論實體和值對象這一組概念。實體是具有唯一標識的對象，而唯一標識會伴隨實體對象整個生命周期并且不可變更。值對象本質上是屬性的集合，并沒有唯一標識。
領域對象在包含值對象的同時也保留了值對象的業務含義，而數據對象可以使用更加松散的結構保存值對象，簡化數據庫設計。
現在假設我們需要管理足球運動員信息，對應的領域模型和數據模型應該如何設計？姓名、身高、體重是一名運動員本質屬性，加上唯一編號可以對應實體對象。跑動距離，傳球成功率，進球數是運動員比賽中的表現，這些屬性的集合可以對應值對象。
值對象在數據對象中可以用松散的數據結構進行存儲，而值對象在領域對象中需要保留其業務含義如下圖所示：
我們根據圖示編寫領域對象與數據對象代碼：
// 數據對象
public class FootballPlayerDO {
private Long id;
private String name;
private Integer height;
private Integer weight;
private String gamePerformance;
}
// 領域對象
public class FootballPlayerDMO {
private Long id;
private String name;
private Integer height;
private Integer weight;
private GamePerformanceVO gamePerformanceVO;
}
public class GamePerformanceVO {
private Double runDistance;
private Double passSuccess;
private Integer scoreNum;
}
抽象的核心是找相同，對不同事物提取公因式。實現的核心是找不同，擴展各自的屬性和特點。例如模板方法設計模式正是用抽象構建框架，用實現擴展細節。
我們再回到數據模型的討論，可以發現腳本化是一種拓展靈活性的方式，腳本化不僅指使用groovy、QLExpress腳本增強系統靈活性，還包括松散可擴展的數據結構。數據模型抽象出了姓名、身高、體重這些基本屬性，對于頻繁變化的比賽表現屬性，這些屬性值可能經常變化，甚至屬性本身也是經常變化，例如可能會加上射門次數，突破次數等，所以采用松散的JSON數據結構進行存儲。
工程理論總是要落地的，落地也是需要一些步驟和方法的。本文我們一起分析一個足球運動員信息管理系統，目標是管理運動員從轉會到上場比賽整條鏈路信息，這個系統大家應該也都沒有接觸過，我們一起來分析。需要說明本實例著重演示DDD方法論如何落地，業務細節可能并不能面面俱到。
梳理流程有兩個問題需要考慮，第一個問題是從什么視角去梳理？因為不同的人看到的流程是不一樣的。答案是取決于系統需要解決的是什么問題，因為我們要管理運動員從轉會到上場比賽整條鏈路信息，所以從運動員視角出發是一個合適的選擇。
第二個問題是對業務不熟悉怎么辦？因為我們不是體育和運動專家，并不清楚整條鏈路的業務細節。答案是梳理流程時一定要有業務專家在場，因為沒有真實業務細節，無法領域驅動設計。同理在互聯網梳理復雜業務流程時，一定要有對相關業務熟悉的產品經理或者運營一起參與。
假設足球業務專家梳理出了業務流程，運動員提出轉會，協商一致后到新俱樂部體檢，體檢通過就進行簽約。進入新俱樂部后進行訓練，訓練指標達標后上場比賽，賽后參加新聞發布會。
四色建模第一種顏色是紅色，表示時標對象。時標對象是四色建模最重要的對象，可以理解為核心業務單據。在業務進行過程中一定要對關鍵業務留下單據，通過這些單據可以追溯出整個業務流程。
時標對象具有兩個特點：第一是事實不可變性，記錄了過去某個時間點或時間段內發生的事實。第二是責任可追溯性，記錄了管理者關注的信息。現在我們分析本系統時標對象有哪些，需要留下哪些核心業務單據。
轉會對應轉會單據，體檢對應體檢單據，簽合同對應合同單據，訓練對應訓練指標單據，比賽對應比賽指標單據，新聞發布會對應采訪單據。根據分析繪制如下時標對象：
這三類對象在四色建模中用綠色表示，我們以電商場景為例進行說明。用戶支付購買商家的商品時，用戶和商家是參與方。物流系統發貨時配送單據需要有配送地址對象，地址對象就是地。訂單需要商品對象，物流配送需要有貨品，商品和貨品就是物。
我們分析本例可以知道參與方包含總經理、隊醫、教練、球迷、記者，地包含訓練地址、比賽地址、采訪地址，物包含簽名球衣和簽名足球：
在四色建模中用黃色表示，這類對象表示參與方、地、物是以什么角色參與到業務流程：
我們可以為對象增加相關描述信息，在四色建模中用藍色表示：
在四色建模過程中我們體會到時標對象是最重要的對象，因為其承載了業務系統核心單據。在劃分領域時我們同樣離不開時標對象，通過收斂相關時標對象劃分領域。
當業務系統發生一件事情時，如果本領域或其它領域有后續動作跟進，那么我們把這件事情稱為領域事件，這個事件需要被感知。
例如球員比賽受傷了，這是比賽子域事件，但是醫療和訓練子域是需要感知的，那么比賽子域就發出一個事件，醫療和訓練子域會訂閱。
例如球員比賽取得進球，這也是比賽子域事件，但是訓練和合同子域也會關注這個事件，所以比賽子域也會發出一個比賽進球事件，訓練和合同子域會訂閱。
通過事件交互有一個問題需要注意，通過事件訂閱實現業務只能采用最終一致性，需要放棄強一致性，這一點可能會引入新的復雜度需要權衡。
接口層：提供面向外部接口聲明和DTO對象
訪問層：提供HTTP訪問入口
業務層：領域層和業務層都包含業務，但是用途不同。業務層可以組合不同領域業務，并且可以增加流控、監控、日志、權限控制切面，相較于領域層更為豐富，提供BO對象
領域層：提供DMO（DomainObject）、VO、事件、數據訪問對象，核心是按照領域進行分包，領域內高內聚，領域間低耦合
外部訪問層：在這個模塊中調用外部RPC服務，解析返回碼和返回數據
基礎層：包含基礎功能，例如緩存工具，消息隊列，分布式鎖，消息發送等功能
我們展開領域層進行分析。領域層的核心是按照領域進行分包，并且提供DMO、VO、事件、數據訪問對象，領域內高內聚，領域間低耦合，例如domain1對應合同子域，domain2對應訓練子域，domain3對應合同子域。
目前為止領域已經確定了，現在可以根據領域劃分任務了，組內成員分別負責一個或多個領域進行詳細設計，這個階段就是大家非常熟悉的用例圖，活動圖，時序圖，數據庫設計，接口設計的用武之地。需要說明的是領域驅動設計不是取代詳細設計，而是為了更清晰地詳細設計。
感謝各位的閱讀，以上就是“DDD建模六個問題與步驟是什么”的內容了，經過本文的學習后，相信大家對DDD建模六個問題與步驟是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
