架構實操：畫好一張業務模型圖

阿里妹導讀

本文以SDK設計的角度分析瞭如何構建一張屬於SDK的各個業務的模型圖。

引言

這個話題源自於SDK部門設計標準的推導。我看過很多介紹技術模型的文章，大部分都是介紹從實體的角度如何畫技術架構圖。但真正介紹業務能力相關的業務模型卻很少。這是因為業務的抽象複用要比技術的抽象複用難得多，而我要介紹的是以SDK設計的角度去分析如何構建一張屬於SDK的各個業務的模型圖。

對接業務是每個開發需要做的事情，對於每個業務的負責人有義務講好自己業務模型的“故事”，引用《人人都是架構師》的一句話：

架構的事情誰來做呢？看一下你座位左邊的，再看一下你座位右邊的，再看一下你主管…. 別看了，他們是要做，你自己也要做，人人都是架構師。

什麼是業務模型圖

什麼是業務模型圖？這個問題在我剛開始實踐畫業務模型圖的時候很困擾我，在我們日常工作中經常能看到各種各樣的有關架構或者是模型的圖，大家對這些圖的理解千人千面，有的會把業務模型圖當成是一個流程圖，有人會把它等同於業務架構圖，也有人會將它理解成是一個介紹業務的圖例。沒有人給出一個具象而標準的定義，我嘗試將這個問題進行如下拆分。

業務模型圖 = 業務模型 + 圖

問題拆分後，則需要解決兩個問題：

●業務模型是什麼？

●圖是什麼？

圖是什麼？這個問題不難回答：業務模型圖是業務模型的具體表達！有點繞？沒關係，可以用一個等式表達：圖 = 業務模型圖 = 業務模型的表達 = 表達業務的模型。

所以我們要解決的問題轉為了：業務模型 + 表達。

什麼是業務模型？

業務模型的本質

透過抽象、聚合、分類等方式，對業務的能力內容、職責範圍（邊界）進行定義。

業務模型的作用

嘗試回憶一下，你是否遇到過這種情況：當別人問你負責的業務具體是做什麼的（業務本質）？為什麼要這麼設計？未來計劃怎麼玩（業務擴充套件）？你很難用一兩句話跟別人講清楚這些內容，就算你花了很多時間跟別人解釋這些事情，他們還是很難聽懂你在講什麼，特別是跨了業務協作、跨域協作（產品、研發、UED），在SDK領域必須面對的還有對上游的解釋，跟他們說清楚對接的模式、對接的方式等等。這時候恨不得把程式碼掏出來一行行的講給他們聽，但就算你把程式碼掏出來，也很難講通整個過程，這是因為每個人的認知背景存在較大差異。

而業務模型及其推導過程可以幫你總結和思考這些東西。

其受眾使用者和應用場景：

○研發：瞭解模組的能力拆解思路和演進邏輯，形成研發內部共識，重點應用在需求承接過程中對必要性和合理性的判斷，或者對模型提出調整建議，形成新的共識。

○產品：瞭解HMI、研發、UED等之間的分工邏輯，重點應用在對於需求合理性的判斷以及客戶/競對價值的挖掘。

如何表達？

瞭解清楚業務模型的內容和作用後，接下來要解決的是“圖”如何表達出來的問題。

要表達什麼？

業務模型要說清楚需求背後的能力演進邏輯，主要包含三個部分的能力內容：

●業務核心：高層次抽象業務關鍵的模組拆解邏輯，需要對現在需求的全面覆蓋對未來有很好的擴充套件考慮。

●基礎能力：在業務承接的基礎上抽象高可複用能力，重點保障業務演進過程的高效能、高質量、開發效率，從分工的角度能夠讓業務開發的團隊給框架的同學講清楚職責要求。

● 對接模式：從SDK平臺型產品特點出發，需要明確SDK使用者的對接模式，追求的是更低的對接成本和更專業的個性化能力。

表達形式

一圖勝千言，業務模型核心還是要透過整體的架構圖來表達。架構核心是橫和縱的考慮。在橫的方面，首先需要選擇SDK業務架構的分層模型，能夠讓各模組業務在推導過程中能夠有相似的表達習慣。

業務架構分層模型可以從業務模型本身想表達的內涵出發考慮：

○面向HMI（Human Machine Interface 人機互動介面）：SDK作為能力提供者，需要滿足HMI（使用者）對業務能力的訴求，在提供業務能力的同時降低HMI的對接門檻。

○面向底層：基於引擎/資料/基礎庫提供的原子能力，進行初步封裝。主要重點保障業務的質量、業務開發效率、業務穩定性的沉澱。

故而業務分層模型可以參照以下的分層結構進行分層，但不侷限於這種分層介面，需要根據自身業務情況來定。

HMI層：基於SDK的業務元件層或模式層的能力，明確業務場景分類邏輯和SDK對接模式；
業務元件層：在模式層的基礎上，面向HMI使用場景的業務封裝，需要有清晰的個性化分類特徵，如何滿足不同層次的訴求；
模式層/框架層：描述業務本質流程的核心業務能力構成；
通用能力層：業務流程無關但是業務依賴的通用能力；
基礎庫/引擎層：涉及到SDK用到的引擎或者基礎庫的核心能力；

如何推導？

推導原則

業務模型的推導過程也是建模的過程，行業中有很多建模的經驗可以參考。其中不侷限於建模的具體方法，而是在於建模背後方法論。有幾個方法選擇更加適合SDK業務特點。整體的推導過程採取“自底向上和自頂向下的結合”的方法論進行推導：

●自頂向下

○門檻更低，歸納的過程需要決策的複雜度低

○從全域性的需求細節出發，重新地、完整地認知業務

●自底向上

○門檻更高，需要直接從要解決的問題出發拆解子問題，需要對領域非常清楚。但這也是SDK業務同學需要具備的能力，且也有一定的業務經驗沉澱。

●自底向上和自頂向下結合

○基於自底向上的建模結果和自頂向下的全域性拆解邏輯互相印證、反覆調整，保障模型整體自洽。

整體流程大致如下：

業務模型是的推導過程是一個分類的過程，分類的過程背後是邏輯推理的過程。邏輯推理的兩種基本模式：歸納和演繹。透過大量的產品PRD作為資訊輸入，使用合理的拆解方法，將需求的輸入資訊拆解成不可再分小點，再嘗試使用業務能力的分類標準將其分類，探求不同分類的可能性，最後將能力根據關係組成有層次、關係明確的業務流程、能力關係圖。

推導步驟與標準

本文章主要介紹自底向上的推導方法論，自頂向下的方法論這邊不做論述。整個推導過程分為了6個步驟：需求收集、能力拆解、能力定義、能力分類、能力分層、資料關係。

那為什麼是這六個步驟呢？這個問題是個很好的問題，根據我們的推導原則和大量的實驗論證，業務模型是基於現有的所有業務（需求），將需求拆解成分散的程式能力項，根據分散的能力項重新組合行成完整的業務結構。故而整體的流程是需求拆能力，再歸納和演繹成業務模型。總體推導過程需要分6個步驟去實現。

具體步驟和執行標準詳情見下文。

能力拆解

能力拆解是將產品的Prd轉化為一個個具有業務能力的能力項的過程，整個拆解過程較為繁瑣。我們經過探索，總結出一個執行方式：

●需求拆解成事件集合

●將事件即可拆解成不可再分的能力子項。

這些能力子項，我們稱之為：“能力項列表”。這些能力項是完成產品Prd，組成整個業務模組的磚頭。

名詞解釋

事件：是指對領域狀態產生重要影響的事件。它通常代表了一項業務事宜的完成或一個重要的變化，例如“使用者註冊成功”、“訂單已支付”、“庫存已更新”等。業務事件通常以過去時態的形式描述，因為它們代表了系統所經歷的某個瞬間的狀態變化。

在能力拆解者的視角中，需求的樣子：

從需求到DDD事件的拆解

具體的操作步驟不再這邊詳細展開，有興趣可以看DDD設計相關內容的介紹。

名詞解釋（引用維基百科）

DDD：領域驅動設計（英語：domain-driven design，縮寫 DDD）是軟體程式碼的結構及語言（類別名稱、類方法、類變數）需符合業務領域中的習慣用法。是一種架構設計方法論，透過邊界劃分，將複雜業務領域簡單化，幫助我們設計出清晰的領域和應用邊界，保證業務模型與程式碼模型的一致性。

這個步驟將需求拆解成事件集合的過程，要關注事件拆解是否出現遺漏，是否準確！！需要窮舉客戶事件，明確客戶所有場景和業務操作，對於不同的訊息事件列表，如果處理邏輯不一樣，需要窮舉所有訊息型別。這個很重要，如果事件拆解的過程出現遺漏，則最後可能出現業務模型的能力項丟失。

這個步驟拆解的結果是得到了事件集合，作為事件拆解成能力項的輸入。

從事件到能力項的拆解準則

在事件拆解的原則中，一個事件可以認為是需求的一個case，對其拆解可以得出完成需求所需的能力項列表。而在拆解過程中一個事件需要對其進行完整的描述，保證拆解的能力項是完整的、不可再分的。

我們要關注的點主要有5大要素：資源、資料、業務、配置、異常。這五大要素描述了事件的輸入、輸出、依賴、場景變化、異常情況等資訊。透過這五大要素，解釋了完成一個事件的所有能力項的完整敘述。具體內容：

●資源：事件資源是執行必不可少的資料內容。比如車標顯示，則需要車標的樣式資源資料。

●資料：事件資料是對事件中所關聯的資料以及陣列組成的靜態描述，需要明確資料項的組成成員，資料流中不再描述資料項具體組成。

●業務：

○業務需要包括觸發場景、資料流、事件處理規則、以及場景對應場景操作；

○規則需要明確資料流的所有處理規則，規則不包括使用者事件，使用者事件需要事件風暴的事件體現；

○場景操作需要指出APP視覺領域的變化，包括UI、主圖、圖層；

○樣式強相關，需要在場景操作中展開事件。

●配置：需要明確客戶在這個過程中使用的配置項，如縮放係數等。

●異常：需要明確業務處理過程中，SDK可能發生的異常。

事件經過五要素拆解後，得到的輸出：“毛坯”能力項，這時的能力項包含了主語、賓語、謂語、定語、狀語等等。

本環節的輸出作為“能力定義”環節的輸入。

能力定義

能力定義是對能力拆解後得到的“毛坯”能力項進行進一步的精細化加工，和針對具象能力的定義。原則是在能力精簡的基礎上，不丟失原有的能力資訊。

能力精簡

業務能力項精簡是去除多餘修飾部分（狀語、補語等），進行簡化。在此基礎上可以對能力進行簡單的歸納。此步驟能夠化繁為簡，減少後續能力分類的工作量。拿拆解後的其中一個能力項舉例分析，該能力項的背景是：在高德地圖車機版上，使用者點選“回家”按鈕後，規劃了一條路線，使用者選擇路線後，點選“開始導航”後，開始進入導航狀態並播報前方路況。

此時，可以去掉對能力項不影響的部分，保留能表達能力項的部分，則會得到兩種情況：

第一種：只去掉無能力項無關的修飾，透過這種方式得到的能力項資訊較多。

第二種：在去除與能力無關的修飾基礎上，進一步去除過度描述業務的名字。

對比這兩種方式，我更傾向於使用第二種方式，是因為在充分描述能力的基礎上，可以做到更精簡的描述業務的能力。在後續的能力分類上可以更好的判斷分類原則。

能力去冗餘

●原則：去除相同，保留不同。

●做法：在業務能力精簡後，再去除相同的能力，只保留一個。

舉栗：在實際事件拆解過程中，拆出了兩個事件：開始導航事件和結束導航事件。這兩個事件分別有通知使用者開始導航狀態、通知使用者結束導航狀態，則這兩個能力項可以認為是同一個：通知使用者導航狀態。

●評價標準：在實操過程中主要是關注以下原則：

○定義程度：是否丟失關鍵實體資訊

○清晰易懂：概念清晰、不需要進一步解釋。

在實際操作測試中，透過不同需求的兩個事件的操作，對其進行能力拆解和能力定義，經過能力拆解、能力定義後，兩個推導步驟下來相似的事件中能力精簡了55%。我們在推導過程中可以抽象出事件很多共性的部分。

能力分類

經過能力定義後，會得到不可再分的精簡能力項列表，至此已經沒有需求的概念了，你手上有的只有一堆混沌、雜亂的能力項列表。我們需要在混沌的世界裡面重新建立一個新的秩序、新的世界。這時候對付這種混沌的世界，我們使用聚類工具讓他們“聞風喪膽”，重新迴歸有序。執行原則和方法，是使用最小生成樹聚類。在分類執行過程中，業務專屬的特定分類原則應優先於通用的分類原則，這是快速的拉齊概念一致的方法。其執行標準如下表：

型別	原則	定義
業務特定分類原則（優先順序高）	業務	業務模組的既定分類原則	多個業務能力的按現有的既定分類原則，進行歸到同一類
	資料	模組的資料既定分類原則	多個業務資料按現有既定的模組分類原則，進行分類
	其他	依據xxx原則	各模組自己定義的原則
通用分類原則（優先順序低）	資料	資料操作實體一致	多個業務的資料互動或操作資料的實體一致，進行歸到同一類
		資料操作型別一致	多個業務的資料本身的特性、操作的具體內容或資料處理的業務邏輯一致，進行歸到同一類。
		資料使用場景一致	多個業務的資料型別不一致，但實際使用場景是同一個，進行歸到同一類。
	業務	業務屬性一致	多個業務的能力獨立提供但業務型別一致，進行歸到同一類
	業務	業務使用場景一致	多個業務的使用場景相似，進行歸到同一類

評價標準

雖然有共同的執行標準，但對於能力分類的結果而言因人而異，不同人歸類的結果必然或多或少存在不同，故而需要在歸類之後反覆的check是否歸類合理，合理性的評價標準如下：

1.完整性：check是否考慮全面；

2.結果獨立互斥：check能力分類是否只符合單項；

3.清晰易懂：概念清晰、不需要進一步解釋；

4.葉子節點的顆粒度相當。

當分類的結果符合以上的評價標準，則對於相同的事件分類結果將殊途同歸，最後結果差別不大。

操作示例

下圖使用簡單的形狀表示不同的能力項，初步分類將業務相同的歸為同一類，從20個能力項得到了8個類別。再透過功能分類相同的歸為同一類，進一步抽象得到了3類業務功能能力。最終從20個能力項變成了3類業務能力，這就是抽象之美。

能力分層

能力分類後將得到能力類列表，此時的類列表在結構上還有所欠缺，無法表達能力類之間的層次關係和結構關係。故而類間關係明確，類之間的關係為類的進一步聚合能力類和類的分層提供了理論支撐。此時我們借鑑程式設計中類關係的定義（但不完全相同）對能力類之間進行關聯，進一步確認類關係。

步驟1：關係明確

根據依賴關係進行初步分層，進一步組合和結構劃分，得出基礎的分層結構圖。

層（塊）關係執行準則：

●並列關係：業務屬於同一大型別，但業務之間沒有交集。則作為一個原子能力被依賴或組合。

●組合關係：根據業務的分類標準對業務能力進一步分類組合，再抽象出一個程度更高的能力分類，被能力類作為子類的形式呈現。

●依賴關係：被依賴的業務能力作為依賴方的基礎能力，被依賴的業務能力作為基礎能力。

步驟2：引入分層模型

在分層結構圖的基礎上，確認業務的核心能力、業務元件能力、基礎能力，根據經典分層結構填入指定層。具體的分層結構需要根據自己業務情況進行制定，這邊提供的經典分層結構是SDK開發中常用的分層結構。

●業務元件層：業務對接能力抽象，解決SDK對接能力的易用性和個性化問題。

●業務模式層：業務核心能力，描述整體業務模式。

●基礎能力層：向下對接引擎能力，向上為業務核心提供能力支撐。

評價標準

在分層操作中，更多的需要關注分層是否合理，以及好不好理解，所以主要關注以下兩點：

●合理性：check是否存在分類的分層不合理；

●清晰易懂：概念清晰、不需要進一步解釋。

操作示例

對能力分類後的能力類列表進行類關係明確（左圖），再根據類關係將其填入到分層模型中，將會得到一張接近完整的業務模型圖。

資料關係

業務模型的大廈在能力分層後即將成形，只剩最後一片烏雲：業務能力層之間的資料的流轉情況。該步驟主要解決層/塊之間的關聯操作的資料關係。在資料關係中，主要關注什麼資料（WHAT）和怎麼流轉（HOW），也就是業務運轉需要什麼資料和對應資料的流向是怎麼樣。首先是資料定義，其歸納的執行標準如下：

●業務特性：根據實際業務模組定義；

●通用特性：能力與能力、層與層之間的互動出入口的資料和對應控制型別的集合。

其次是資料流，其歸納的執行標準如下：

●單向資料流：資料只朝一個方向流動（沒有反饋控制的處理結果）；

●雙向資料流：資料可以在兩個方向之間流動（反饋控制的處理結果）；

●參與者與角色：資料的生產者（生成資料的系統）與消費者（處理或使用資料的系統）。

評價標準

在資料關係中，最後check的部分主要關注在資料的完整性和清晰度上，主要為：

●完整性：check是否考慮全面；

●清晰易懂：概念清晰、不需要進一步解釋。

操作示例

根據層與層之間的資料集合進行分類，假設得到了“xx業務控制”、“xxx業務控制結果通知”等資料類，對其資料流向進行定義後填入到圖中，將得到右圖完整的業務模型圖。

業務模型圖的評價標準

在業務模型圖出來後，需要反覆check業務模型是否符合業務情況，主要需要關注以下幾點：

維度	子維度	要求
正確性	需求匹配度高	需要綜合對SDK內、外客戶的全部需求場景歸納總結。
正確性	需求變更過程可追溯	業務模型需要考慮持續迭代，對於任何新的需求都需要帶入模型判斷是否存在需要修正。
擴充套件性	滿足現有需求	實踐是最好的檢驗標準，需要結合生態主流的客戶的需求說明業務模式的合理性。
擴充套件性	應對未來業務變化	業務模式抽象對於未來業務的整體的縱、橫向擴充套件下能夠保障架構的穩定。
清晰性	美觀	本質是一張結構圖，還是要追求讓閱讀者能夠對圖形整體的配色、佈局、字型等保證友好的閱讀效果。
	結構簡單	目標客戶包含了業務同學，甚至是其他弱相關的同學，需要把業務表達地更加簡單易懂，而不是追求內容的豐富。
	分類清晰	整體業務模型要解決的是把一堆的能力項擺放到合適的層、模組、子模組等，本質也是一個分類的過程，每個分類的依據要有很強的特徵能夠讓閱讀者感受到。