1. 從“靜態(tài)”到“動態(tài)”為什么我們需要行為圖在軟件設(shè)計和系統(tǒng)分析的世界里我們常常從“靜態(tài)”開始。類圖、組件圖、部署圖這些UML圖描繪了系統(tǒng)的骨骼和器官——有哪些類、它們?nèi)绾侮P(guān)聯(lián)、系統(tǒng)由哪些部分組成、最終部署在哪里。這就像拿到了一張建筑的結(jié)構(gòu)藍圖知道了承重墻在哪、房間如何布局。但光有藍圖我們無法知道這棟樓里人們一天的生活是如何流動的早晨如何從臥室走到廚房晚上客廳的燈光如何依次亮起又熄滅訪客按門鈴后主人如何響應(yīng)。要理解這些“動態(tài)”的行為我們就需要UML中的行為圖。行為圖的核心任務(wù)就是捕捉系統(tǒng)在運行時的“活”的狀態(tài)。它關(guān)注的是對象如何隨著時間變化如何響應(yīng)事件以及一系列動作如何按順序或并發(fā)地執(zhí)行。在UML的眾多行為圖中狀態(tài)圖和活動圖是兩種最常用、也最容易被混淆的利器。很多人覺得它們看起來有點像都是帶箭頭的框框但它們的關(guān)注點和適用場景有著本質(zhì)區(qū)別。簡單來說狀態(tài)圖關(guān)注的是“對象在特定條件下會變成什么樣”它描繪的是一個對象或系統(tǒng)在其生命周期內(nèi)因事件觸發(fā)而在不同狀態(tài)間遷移的歷程。而活動圖關(guān)注的是“為了完成一件事需要按什么步驟做”它更像一個流程圖描述了從活動到活動的控制流和數(shù)據(jù)流。理解并正確使用這兩種圖是設(shè)計清晰、健壯、可維護系統(tǒng)的關(guān)鍵。狀態(tài)圖能幫你精準定義業(yè)務(wù)實體的復(fù)雜生命周期比如訂單從“待支付”到“已發(fā)貨”再到“已完成”的完整旅程避免出現(xiàn)“幽靈狀態(tài)”或非法狀態(tài)遷移活動圖則能幫你梳理清晰的業(yè)務(wù)流程比如用戶從登錄、瀏覽商品、下單到支付的完整操作序列或者規(guī)劃復(fù)雜的算法邏輯。接下來我們就深入這兩種圖的內(nèi)部看看它們各自如何工作以及在實際項目中如何選擇和應(yīng)用。2. 狀態(tài)圖描繪對象的生命律動狀態(tài)圖有時也叫狀態(tài)機圖它描述了一個對象在其生命周期內(nèi)所經(jīng)歷的狀態(tài)序列以及導(dǎo)致狀態(tài)轉(zhuǎn)換的事件和動作。它的核心建模元素是“狀態(tài)”和“遷移”。想象一下一臺老式的CD播放機它可能有“關(guān)機”、“待機”、“播放”、“暫停”、“彈出”等狀態(tài)。當(dāng)你按下“播放”鍵事件它從“待機”狀態(tài)遷移到“播放”狀態(tài)同時執(zhí)行“啟動光盤旋轉(zhuǎn)并讀取數(shù)據(jù)”的動作。這就是狀態(tài)圖要刻畫的東西。2.1 狀態(tài)圖的核心構(gòu)成要素一個完整的狀態(tài)圖由以下幾個關(guān)鍵部分組成理解它們是畫好狀態(tài)圖的第一步。狀態(tài)表示對象生命周期中的一個階段或條件。在狀態(tài)持續(xù)期間對象會滿足某些條件、執(zhí)行某些活動或等待某些事件。狀態(tài)用一個圓角矩形表示。初態(tài)和終態(tài)初態(tài)用一個實心圓點表示代表對象生命周期的起點終態(tài)用一個圓圈套一個實心圓點表示代表對象生命周期的結(jié)束可能是銷毀也可能是完成使命。簡單狀態(tài)與復(fù)合狀態(tài)簡單狀態(tài)內(nèi)部沒有子結(jié)構(gòu)。復(fù)合狀態(tài)則可以包含嵌套的子狀態(tài)機這對于建模復(fù)雜的狀態(tài)行為非常有用可以分層細化。遷移表示狀態(tài)之間的變化由某個事件觸發(fā)。用一條帶箭頭的實線表示從源狀態(tài)指向目標狀態(tài)。遷移上可以標注三個部分事件 [守衛(wèi)條件] / 動作。事件觸發(fā)狀態(tài)遷移的事情如“收到付款”、“超時”、“用戶取消”。守衛(wèi)條件一個布爾表達式寫在方括號[]里。只有當(dāng)事件發(fā)生且守衛(wèi)條件為真時遷移才會發(fā)生。例如“收到訂單 [庫存0]”。動作在遷移發(fā)生時立即執(zhí)行的、不可中斷的操作寫在斜杠/后面。例如“/ 扣減庫存”。內(nèi)部活動在狀態(tài)內(nèi)部執(zhí)行的活動。寫在狀態(tài)框內(nèi)格式為活動類型 描述。常見的活動類型有entry / 動作進入該狀態(tài)時執(zhí)行的動作。exit / 動作離開該狀態(tài)時執(zhí)行的動作。do / 活動在該狀態(tài)處于激活狀態(tài)時持續(xù)執(zhí)行的活動如“播放音樂”。event / 動作在該狀態(tài)下特定事件觸發(fā)并執(zhí)行一個動作但不引起狀態(tài)遷移這很重要。2.2 一個電商訂單的狀態(tài)圖實戰(zhàn)理論有點抽象我們用一個經(jīng)典的電商訂單狀態(tài)機來實戰(zhàn)一下。假設(shè)一個訂單有以下幾個核心狀態(tài)待支付、已支付、備貨中、已發(fā)貨、已完成、已取消。graph TD A[初態(tài)] -- B[待支付] B -- 用戶支付 / 更新支付時間 -- C[已支付] B -- 用戶取消 / 釋放庫存 -- F[已取消] C -- 系統(tǒng)檢查庫存 / 鎖定庫存 -- D[備貨中] D -- 倉庫揀貨打包完成 / 生成運單 -- E[已發(fā)貨] E -- 用戶確認收貨 / 結(jié)算給商家 -- G[已完成] C -- 用戶申請退款 -- H((退款中)) H -- 退款成功 / 釋放庫存 -- F H -- 退款駁回 -- C D -- 用戶取消發(fā)貨前 / 釋放庫存 -- F注上圖僅為示意圖實際UML狀態(tài)圖使用標準圖形符號我們來拆解這個狀態(tài)圖背后的設(shè)計邏輯初態(tài)訂單創(chuàng)建成功立即進入待支付狀態(tài)。這里通常隱含了一個entry動作比如“生成訂單號”、“記錄創(chuàng)建時間”。從待支付遷移這里有兩個互斥的遷移。事件用戶支付。守衛(wèi)條件支付金額等于訂單金額且支付渠道有效。動作更新支付狀態(tài)與時間。完成后進入已支付狀態(tài)。事件用戶取消。動作釋放預(yù)占的庫存如果創(chuàng)建訂單時預(yù)占了庫存。完成后進入已取消狀態(tài)這是一個終態(tài)。已支付狀態(tài)進入此狀態(tài)時可能執(zhí)行entry / 發(fā)送支付成功通知。這個狀態(tài)可能不會停留太久系統(tǒng)會觸發(fā)一個自動的遷移。事件可以是系統(tǒng)檢查庫存這是一個內(nèi)部或自動事件。守衛(wèi)條件[所有商品庫存充足]。動作鎖定庫存。然后遷移到備貨中。這里引入了一個新狀態(tài)退款中。當(dāng)事件用戶申請退款發(fā)生時從已支付遷移到退款中。這是一個重要的設(shè)計它表明“退款”是一個可能需要人工審核或第三方支付接口處理的獨立子流程在此期間訂單主狀態(tài)懸停。復(fù)合狀態(tài)與并發(fā)備貨中可以設(shè)計成一個復(fù)合狀態(tài)。它內(nèi)部可能包含并發(fā)的子狀態(tài)揀貨、打包、質(zhì)檢。只有當(dāng)所有這些子活動都完成后整個備貨中狀態(tài)才完成觸發(fā)倉庫作業(yè)完成事件遷移到已發(fā)貨。并發(fā)用水平粗線分叉與匯合表示這清晰地展示了業(yè)務(wù)流程中的并行環(huán)節(jié)。狀態(tài)內(nèi)的內(nèi)部事件在已發(fā)貨狀態(tài)我們可能想處理“用戶查詢物流”這個事件但這不改變訂單狀態(tài)。我們可以寫在狀態(tài)框內(nèi)物流查詢 / 返回物流信息。這是一個event/動作的典型例子。終態(tài)已完成和已取消都是終態(tài)。進入終態(tài)意味著該訂單對象的核心生命周期結(jié)束。2.3 繪制狀態(tài)圖的避坑指南與心得畫了這么多年狀態(tài)圖我總結(jié)出幾個最容易踩坑的地方坑一把系統(tǒng)級流程和對象狀態(tài)混為一談。狀態(tài)圖應(yīng)該專注于一個對象或一個緊密關(guān)聯(lián)的聚合對象如訂單的狀態(tài)變化。如果你發(fā)現(xiàn)圖上出現(xiàn)了“用戶”、“庫存系統(tǒng)”、“物流系統(tǒng)”等不同對象的行為那很可能畫成了活動圖或序列圖。狀態(tài)圖的視角始終跟隨一個對象。坑二濫用復(fù)合狀態(tài)和并發(fā)。復(fù)合狀態(tài)是管理復(fù)雜性的利器但過度使用會讓圖變得難以理解。一個經(jīng)驗法則是如果一組子狀態(tài)緊密相關(guān)并且它們與外界的交互方式一致即進入/退出這組狀態(tài)的事件是統(tǒng)一的那么就將它們封裝成復(fù)合狀態(tài)。并發(fā)狀態(tài)要謹慎使用確保并發(fā)的子狀態(tài)在邏輯上確實是獨立的并且有明確的同步點匯合。坑三遺漏異常和超時路徑。這是業(yè)務(wù)邏輯漏洞的主要來源。在待支付狀態(tài)除了“支付”和“取消”是否要考慮“超時未支付自動取消”在備貨中狀態(tài)如果某個商品缺貨了怎么辦是遷移到一個部分缺貨狀態(tài)還是直接取消訂單這些邊界情況必須在狀態(tài)圖中體現(xiàn)出來通常通過時間事件如after(30分鐘)或異常事件來觸發(fā)遷移?？铀膭幼鰽ction與活動Activity混淆。在狀態(tài)內(nèi)部do/活動指的是一個需要時間才能完成的過程比如“播放視頻”對象可以在這個過程執(zhí)行期間響應(yīng)其他事件。而遷移上的動作或entry/exit動作應(yīng)該是瞬時完成的、原子性的操作比如“計數(shù)器加一”、“發(fā)送消息”。如果將一個耗時的操作放在遷移動作上在邏輯上意味著狀態(tài)遷移被阻塞這通常不是好的設(shè)計。個人心得在項目初期我習(xí)慣用狀態(tài)圖來和技術(shù)團隊、甚至產(chǎn)品經(jīng)理溝通復(fù)雜業(yè)務(wù)實體的規(guī)則。一張清晰的狀態(tài)圖比幾十頁的需求文檔更直觀能暴露出許多流程上的歧義和漏洞。畫完圖后一個很好的驗證方法是沿著圖中的每一條路徑在腦子里“跑”一遍各種正常和異常的業(yè)務(wù)場景看看是否都能到達預(yù)期的終態(tài)有沒有“死胡同”無法遷移出去的非終態(tài)或者“黑洞”非法遷移。3. 活動圖刻畫過程的步驟與決策如果說狀態(tài)圖是對象的“個人傳記”那么活動圖就是一項工作的“操作規(guī)程”或一個用例的“劇本”。它專注于描述從一個活動到另一個活動的控制流也可以展示并發(fā)的流和數(shù)據(jù)流?；顒訄D脫胎于流程圖但比傳統(tǒng)流程圖更強大因為它正式支持并發(fā)、分區(qū)泳道和對象流。3.1 活動圖的核心構(gòu)成要素活動圖的元素更貼近我們熟悉的流程概念?；顒颖硎疽粋€工作單元或任務(wù)步驟用一個圓角矩形表示。它可以是原子的也可以被分解成另一個活動圖。例如“驗證用戶身份”、“計算訂單總價”、“調(diào)用支付接口”?？刂屏鞅硎净顒又g的執(zhí)行順序用帶箭頭的實線表示。這就是流程的主線。初始節(jié)點與活動最終節(jié)點初始節(jié)點用一個實心圓點表示標志流程開始?；顒幼罱K節(jié)點用一個圓圈套一個實心圓表示標志整個活動流程的終止。注意還有一個流最終節(jié)點一個圓圈內(nèi)加一個叉它只終止當(dāng)前的控制流不影響其他并發(fā)的流。決策節(jié)點與合并節(jié)點決策節(jié)點菱形表示一個分支選擇通常有一個流入和多個帶守衛(wèi)條件的流出。合并節(jié)點也是菱形則將多個可選路徑匯合成一個流出。它們通常成對出現(xiàn)用于表示if...else...或switch邏輯。分叉節(jié)點與匯合節(jié)點分叉節(jié)點一條粗水平線將一個控制流拆分成多個并發(fā)的執(zhí)行流。匯合節(jié)點另一條粗水平線等待所有并發(fā)的流都到達后再合并成一個流繼續(xù)執(zhí)行。這是活動圖支持并發(fā)的關(guān)鍵。分區(qū)也叫泳道用垂直或水平的線將活動圖分區(qū)每個分區(qū)代表一個責(zé)任區(qū)域如一個組織單元用戶、系統(tǒng)、后臺服務(wù)、一個角色客戶、客服、管理員或一個對象。它能清晰地表達“誰負責(zé)做什么”。對象流可以顯示活動如何輸入和輸出對象數(shù)據(jù)。用虛線箭頭表示連接活動和對象節(jié)點一個矩形。這有助于理解數(shù)據(jù)在流程中的傳遞和變換。3.2 一個用戶在線購物的活動圖剖析讓我們用活動圖為“用戶在線購買商品”這個業(yè)務(wù)流程建模。為了清晰我們使用泳道來區(qū)分“用戶”、“Web前端”、“訂單服務(wù)”和“支付服務(wù)”的責(zé)任。| 用戶 | Web前端 | 訂單服務(wù) | 支付服務(wù) | |---------------|----------------|-------------------|-------------------| | [開始] | | | | | 瀏覽商品 | | | | | 添加至購物車 | | | | | | 提交購物車頁面 | | | | | | 創(chuàng)建待支付訂單 | | | | | [庫存檢查] | | | | | 庫存充足? | | | | | (是) 鎖定庫存 | | | | | (否) 返回缺貨信息 | | | | 顯示訂單確認頁 | | | | 選擇支付方式 | | | | | 確認支付 | | | | | | 調(diào)用支付API | | 生成支付流水 | | | | | 跳轉(zhuǎn)至支付網(wǎng)關(guān) | | [在支付網(wǎng)關(guān)完成支付] | | | | | | | | 接收支付回調(diào) | | | | 更新訂單為已支付 | | | | 顯示支付成功頁 | | | | | | 異步通知倉庫備貨 | | | [結(jié)束] | | | |注這是一個簡化的文本表示意在展示泳道和活動序列的邏輯。實際繪圖應(yīng)使用UML圖形工具。我們來分析這個活動圖揭示的設(shè)計要點明確的責(zé)任邊界泳道一眼就能看出“創(chuàng)建訂單”、“鎖庫存”是訂單服務(wù)的職責(zé)“生成支付流水”是支付服務(wù)的職責(zé)。這非常有助于進行微服務(wù)或模塊的職責(zé)劃分。并發(fā)性的體現(xiàn)在“更新訂單為已支付”之后活動分為兩條線。一條是同步的流向“顯示支付成功頁”給用戶即時反饋另一條是異步的“異步通知倉庫備貨”。在活動圖中這可以用一個分叉節(jié)點來表示這兩件事可以同時進行無需等待對方。這反映了現(xiàn)實系統(tǒng)中為了提高響應(yīng)速度而采用的常見設(shè)計。決策邏輯清晰“庫存檢查”后的決策節(jié)點清晰地給出了兩條路徑庫存充足則繼續(xù)鎖定庫存庫存不足則直接返回錯誤信息給前端流程終止或?qū)蛞粋€異常處理流程圖中未展開。這種明確的決策點是梳理業(yè)務(wù)規(guī)則的關(guān)鍵。對象流的潛在應(yīng)用我們可以補充對象流。例如“創(chuàng)建待支付訂單”活動會產(chǎn)生一個“訂單對象”這個對象會作為輸入傳遞給“鎖定庫存”和后續(xù)的“更新訂單為已支付”等活動。用虛線箭頭標出這些對象流能讓數(shù)據(jù)傳遞一目了然。3.3 活動圖實戰(zhàn)技巧與常見誤區(qū)活動圖看似簡單但要用好需要注意以下幾點技巧一選擇合適的粒度?；顒訄D可以畫得很高層如“處理客戶訂單”也可以畫得很詳細如“驗證信用卡號的算法步驟”。我的經(jīng)驗是用于描述跨角色/系統(tǒng)的業(yè)務(wù)流程時活動圖最有效。此時每個活動應(yīng)該對應(yīng)一個有意義的工作單元比如“客服審核申請”、“系統(tǒng)發(fā)送確認郵件”而不是“變量i加1”。過細的粒度會讓圖變得冗長失去溝通價值。技巧二善用泳道但別過度。泳道是活動圖的靈魂它能清晰劃分職責(zé)。但泳道也不宜過多通常3-5個為宜代表流程中主要的參與方。如果參與方太多可以考慮將一些內(nèi)部協(xié)作緊密的服務(wù)合并到一個泳道如“后端服務(wù)”或者分層繪制先畫一個高層的跨系統(tǒng)圖再為某個復(fù)雜系統(tǒng)畫一個內(nèi)部的活動圖。技巧三區(qū)分控制流與數(shù)據(jù)流。初學(xué)者常把數(shù)據(jù)和操作混在一起畫。記住實線箭頭是控制流表示“做完A后做B”。虛線箭頭是對象流表示“活動A產(chǎn)生了數(shù)據(jù)X活動B需要消費X”。不是所有數(shù)據(jù)都需要畫出來只畫出關(guān)鍵的業(yè)務(wù)對象如訂單、支付單、物流單即可。常見誤區(qū)一把活動圖當(dāng)成代碼流程圖。這是最大的誤解?；顒訄D用于建模業(yè)務(wù)過程或系統(tǒng)工作流它不關(guān)心具體的編程語言實現(xiàn)。圖中的“活動”可能對應(yīng)著一行代碼、一個函數(shù)、一個服務(wù)接口調(diào)用甚至是一段人工操作。它的目的是溝通和設(shè)計而非直接指導(dǎo)編碼。常見誤區(qū)二忽視異常流和取消流。和狀態(tài)圖一樣只畫“陽光大道”是不夠的。支付可能失敗網(wǎng)絡(luò)可能超時用戶可能中途關(guān)閉頁面。這些異常路徑應(yīng)該在活動圖中有所體現(xiàn)可以通過決策節(jié)點導(dǎo)向不同的異常處理活動或者使用中斷活動區(qū)域一種高級特性來建?？芍袛嗟牧鞒?。個人心得在敏捷開發(fā)中我經(jīng)常用活動圖來梳理用戶故事User Story的驗收標準。和產(chǎn)品經(jīng)理、測試人員一起在白板上畫出核心流程的泳道活動圖過程中大家會對“這一步到底誰來做”、“這個異常情況怎么處理”等問題達成一致這張圖隨后就可以作為開發(fā)和測試的共同依據(jù)。它比純文字的描述性驗收標準直觀得多。4. 狀態(tài)圖 vs. 活動圖關(guān)鍵差異與選型指南到了這里你可能已經(jīng)感覺到兩者的不同但面對一個具體問題時到底該用狀態(tài)圖還是活動圖這里有一個清晰的對比和選型指南。4.1 本質(zhì)區(qū)別對比我們可以從幾個維度進行對比對比維度狀態(tài)圖活動圖核心焦點單個對象在其生命周期內(nèi)的狀態(tài)變化。一系列活動組成的過程或工作流。主要元素狀態(tài)、遷移事件、守衛(wèi)、動作、初態(tài)、終態(tài)?；顒印⒖刂屏?、決策/合并節(jié)點、分叉/匯合節(jié)點、泳道。時間維度強調(diào)狀態(tài)在時間上的持續(xù)性。對象會在一個狀態(tài)停留等待事件。強調(diào)活動在時間上的序列性或并發(fā)性。一個活動完成立即轉(zhuǎn)向下一個。驅(qū)動因素由外部或內(nèi)部事件驅(qū)動狀態(tài)遷移。由前一個活動的完成來驅(qū)動控制流前進。并發(fā)表示通過復(fù)合狀態(tài)中的正交區(qū)域來表示并發(fā)子狀態(tài)。通過分叉和匯合節(jié)點來表示并發(fā)的控制流。最佳適用場景建模具有復(fù)雜、清晰狀態(tài)的生命周期對象。如訂單、工單、用戶賬戶、游戲角色、設(shè)備控制器。建模業(yè)務(wù)流程、用例場景、算法流程或跨組件的協(xié)作流程。如用戶注冊流程、訂單處理流程、數(shù)據(jù)導(dǎo)出流程。一個簡單的記憶口訣狀態(tài)圖看“對象”活動圖看“流程”。4.2 實戰(zhàn)選型用例子說話場景A設(shè)計一個“審批請假單”的功能。狀態(tài)圖視角我們會關(guān)注“請假單”這個對象本身。它的狀態(tài)可能是草稿、已提交、部門經(jīng)理審批中、HR審批中、已批準、已駁回、已取消。事件包括員工提交、經(jīng)理通過、經(jīng)理駁回、HR通過、HR駁回、申請人取消。狀態(tài)圖能清晰地定義從草稿到終態(tài)已批準或已駁回的所有合法路徑以及每個狀態(tài)下可以執(zhí)行的操作如只有草稿狀態(tài)才能取消?；顒訄D視角我們會關(guān)注“審批流程”這個動作序列。泳道可能包括員工、部門經(jīng)理、HR?；顒影ㄌ顚懻埣賳?、提交申請、經(jīng)理審核、HR備案、發(fā)送通知。活動圖能展示出串行或并行的審批步驟例如超過10天的假期可能需要經(jīng)理和HR并行審批以及每個步驟由誰負責(zé)。如何選如果你需要嚴格定義請假單的業(yè)務(wù)規(guī)則和生命周期防止出現(xiàn)非法狀態(tài)如“已批準的請假單又被駁回”用狀態(tài)圖。如果你需要向團隊成員解釋整個審批過程是如何一步步進行的各個角色如何配合用活動圖。在大型系統(tǒng)中兩者常結(jié)合使用用狀態(tài)圖定義核心領(lǐng)域?qū)ο笳埣賳蔚膬?nèi)部邏輯用活動圖定義跨服務(wù)的業(yè)務(wù)流程。場景B實現(xiàn)一個“文件上傳”服務(wù)。狀態(tài)圖視角關(guān)注“上傳任務(wù)”對象。狀態(tài)等待中、上傳中、校驗中、轉(zhuǎn)碼中、已完成、已失敗。事件用戶選擇文件、分片上傳完成、MD5校驗通過、轉(zhuǎn)碼成功、網(wǎng)絡(luò)超時、校驗失敗。狀態(tài)圖非常適合定義任務(wù)的重試邏輯例如在上傳中狀態(tài)遇到網(wǎng)絡(luò)超時事件可能遷移回等待中狀態(tài)進行重試。活動圖視角關(guān)注“上傳流程”。活動前端分片、上傳分片至服務(wù)器、服務(wù)器合并文件、計算文件哈希、與源文件哈希比對、異步轉(zhuǎn)碼、通知用戶。活動圖可以清晰展示哪些步驟是順序的必須先合并才能計算哈希哪些是可以并發(fā)的多個分片同時上傳以及異常路徑哈希比對失敗則刪除文件。如何選如果你在設(shè)計一個可靠的上傳任務(wù)調(diào)度器需要精確管理每個任務(wù)的狀態(tài)機用狀態(tài)圖。如果你在編寫上傳服務(wù)的架構(gòu)設(shè)計文檔需要說明各個微服務(wù)前端、網(wǎng)關(guān)、上傳服務(wù)、校驗服務(wù)、轉(zhuǎn)碼服務(wù)如何協(xié)作完成一次上傳用活動圖。4.3 我的混合使用策略在實際項目中我很少孤立地使用某一種圖。它們是一個工具箱里的不同工具。需求分析階段多用活動圖與業(yè)務(wù)方溝通梳理主干和異常流程明確角色職責(zé)。這時活動圖是探索和達成共識的工具。領(lǐng)域設(shè)計階段針對識別出來的核心領(lǐng)域?qū)嶓w如訂單、合同、設(shè)備使用狀態(tài)圖來精確定義其生命周期和業(yè)務(wù)規(guī)則。這相當(dāng)于為這些實體編寫了一份“憲法”后續(xù)的代碼實現(xiàn)如使用狀態(tài)模式將直接以此為依據(jù)。系統(tǒng)設(shè)計階段對于復(fù)雜的跨服務(wù)流程再次使用活動圖但此時的泳道可能變成了各個微服務(wù)或子系統(tǒng)活動變成了服務(wù)間的API調(diào)用。同時可以引用狀態(tài)圖來說明關(guān)鍵服務(wù)內(nèi)部的核心狀態(tài)變化。記住沒有“最好”的圖只有“最合適”的圖。選擇的標準永遠是你想傳達什么信息以及給誰看。給產(chǎn)品經(jīng)理看業(yè)務(wù)流程用活動圖。給后端開發(fā)講訂單狀態(tài)機用狀態(tài)圖。很多時候把兩者放在同一份設(shè)計文檔里相互參照能產(chǎn)生一加一大于二的效果。