如何在短頻快的節奏中做好技術？業務開發必會的架構思維

　　本文提供一種業務架構設計模式：從業務&技術兩個角度提煉出一個基礎思維框架，供業務線開發同學參考。

　　背景介紹

　　我們是CRO面向商家的業務技術團隊，做商家營商環境治理業務已經4年了。作為垂直型業務技術團體（區別於平臺技術團隊），我們也面臨大部分業務技術團隊的拷問：業務技術與平臺技術的差別是什麼？業務技術如何做？如何理解業務？如何在短頻快的業務節奏中做好技術？部分問題有答案；部分依然在尋找更好的答案。本文是對過去四年的總結：從業務&技術兩個角度提煉出一個基礎思維框架，供業務線開發同學參考。

　　業務視角：業務驅動技術是前臺業務的特點，業務開發要逐漸培養自己全域性視角看業務的能力：從交付價值角度理解業務模式；從能力規劃角度掌握產品方向。本文的第一部分介紹價值引領業務架構的做法

　　技術視角：應用架構的內容很大，本文第二部分介紹了架構設計的兩種方法（風格），以及域劃分和流程建模兩個架構關注點　　

　　業務架構

　　業務架構目的

　　業務架構範圍比較大，本文借用“業務架構”這個詞想講的內容是：業務開發應該如何關注&分析業務問題；如何理解業務以及指導系統設計

　　業務架構做什麼

　　業務架構最重要的是"看全域性"（每個人立場/角度/高度不同，對“全域性”的理解不同)，這裡強調的是：向外看的意識，而不是如何看的方法。從三個點出發看全域性：

　　看清楚 "事"：從宏觀角度看“事”是價值源點，是業務戰略&目標&價值；從微觀來看“事”是業務流程。看清楚"事"就理解了“為什麼做”和“怎麼做”的2個核心問題。以我們做的業務為例：宏觀的"事"就是幫助商家低成本處理風險問題，降低商家經營成本，提高平臺競爭力；微觀的“事”包括了商家風險預警流程，風險反饋流程等。看的階段儘量脫離具體系統/業務，向高度和廣度擴充視野。以風險預警為例：從廣度上看，風險是如何識別的（有哪些上游），如何透出的（需要什麼內容），怎麼觸達商家；從高度上看，有多少種風險可以預警（共性是什麼），商家怎麼處理（成本如何等），是否有更優的處理方式。

　　理清楚 "人"： 誰（利益相關者）一起做這件“事”。對利益相關者進行分類管理，識別使用者的不同訴求，排序優先順序。關鍵點是使用者要什麼（使用者視角的，而不是外部視角）。

　　分清楚 "責"： 不同"人“的權&責，在流程中的角色。從產品建設角度出發，人&權&責的識別為了深入瞭解使用者訴求，設計產品能力。例如商家產品需要考慮商家不同角色員工的權&責，以及不同角色需要的產品功能。

　　業務架構怎麼做

　　看清楚事-價值流/能力對映

　　價值流: 價值流是從利益相關者（客戶、終端使用者或工作所產生的產品、服務或交付品的接收者）的視角來描述描述一個端到端價值交付的完整過程。

　　業務能力: 業務能力是業務為實現特定目的或結果而可能擁有或交換的特定能力或產能

　　能力/價值流對映: 將業務能力對映到價值流中的每個階段的過程，用於突出哪些能力對業務運營有著或大或小的重要性

　　分析價值流有助於從更宏觀視角理解業務全過程：價值交付過程拆解成若干階段，由不同的角色協作完成；每個階段需要不同的能力。透過分析能力現狀（完備，缺失，部分滿足），評估價值&緊迫度，可以對未來規劃形成構思。下圖是Togaf招聘員工價值流的示例圖，該圖描述了招聘員工的完整流程和產品能力訴求，透過顏色區分不同能力的現狀（綠色代表滿足訴求；黃色代表部分滿足；紅色代表能力缺失）。　　

　　理清楚人&責-角色分析

　　使用UML用例圖描述業務中的"人"和責。營商業務裡有3種角色，各角色責任如下圖展示　　

　　有了全域性的人&責概覽後，透過分析特定場景工作模式可以發現需求，問題或解決機會。這裡的轉變是：不只關注當前單個需求，而是從全域性視角看業務訴求，從而對需求的合理性，重要性有更合理的判斷；為設計方案提供業務視角考慮。例如下圖例子描述員工招聘的工作模式。(從中可以看出入職階段有提升較大空間）　　

　　應用架構

　　架構：元件的結構、它們之間的相互關係，以及關於元件設計和隨時間演變的原則和指南。

　　架構做的事情主要是：識別元件，定義關係，確定原則。元件和設計視角相關，不同視角下元件的形式/粒度:

　　DDD：子域就是元件，域之間的關係，域設計原則

　　流程視角：流程，子流程，階段都是元件；定義不同粒度下元件的互動關係和原則

　　資料視角：資料表是元件，表之間的關係，和設計原則（正規化和反正規化）

　　架構分層：層是元件，分層互動的關係和原則

　　....

　　本文將介紹兩種通用設計方法（自上而下，自下而上），以及領域建模和流程建模的相關知識。

　　架構方法

　　自上而下

　　自上而下設計是指參考標準方案，裁剪/適配形特定解決方案的過程。很多業務域已有標準模型或解決方案（例如財務域，電商，供應鏈等），這些業務域採用自上而下方法是一個不錯的選擇。設計師經驗豐富/知識面廣適合採用該方法；當然如果設計師經驗不足，也可主動調研後實踐。在大部分業務自上而下方法使用不多，不詳細展開。

　　自下而上

　　自上而下設計是指從具體的業務細節出發，分析歸納最後得出解決方案的過程。自下而上是我們在日常業務中經常使用的方法，本文重點介紹如何做自下而上的設計。

　　自下而上"三板斧"

　　我們從實踐總結出自下而上設計的"三板斧"，作為框架指導設計過程：　　

　　第一招：自下而上做歸納

　　分析問題空間，透過歸納分類減少複雜度。分為兩個過程：場景梳理 和 場景分類

　　場景梳理：羅列所有問題細節。例如：流程建模先羅列所有子流程；領域建模先羅列所有域內概念

　　場景分類：劃分型別，合併同類項。找準分類是對問題空間資訊的提煉，有些分類很容易；有些分類的識別需要一個迭代過程：

　　先根據經驗或直覺選主要的劃分維度，識別型別

　　將場景歸入對應分類

　　遇到難以歸納的場景，則評估是否需調整分類

　　第二招：抽象分析出設計

　　所謂方案是解決方案空間裡的解法，設計過程就是就是從問題空間過渡到解決方案空間。這是過程中的難點，也是最困難的點。設計結果視目標而定（有時是領域模型；有時是流程框架等），使用的方法也需結合問題而定。

　　第三招：自上而下驗場景

　　設計方案要放在設計場景裡進行"推演"。推演的過程很重要：既要推演已知的場景，評估是否滿足現有需求；也要對可能性高的未來場景進行推演，評估未來的適應性。

　　架構實踐

　　領域建模

　　本文不贅述領域建模的具體方法，只討論下“子域劃分”的問題。雖然有很多文章介紹子域識別的方法，對域劃分還是比較難掌握的。如果你見到在某個業務應用裡劃分5+子域，有些子域裡只有少數幾個物件或方法，不要覺得奇怪，這些子域很可能是模仿教課書方法的產物；也可能是拍腦袋得到（常見情況），很多域都是"憑感覺"劃分的（例如很多應用都有“配置域”）。

　　看個例子：下圖的領域模型能找到清晰的子域邊界嗎？在模型中找出連線少部分畫分界線，兩邊連線越少說明邊界越清晰。下圖很難找出清晰且適合邊界，但是設計方案裡分了4個子域，這樣的域劃分是值得推敲的。（PS:看圖說話是領域劃分裡一個直觀好用的方法）　　

　　域的目的

　　回到域劃分的初衷：域劃分的目的。域劃分和維護是有成本的（成本不低），付出了成本就要考慮收益，域劃分的目的（即收益）到底是什麼？我認為最重要的有兩點：

　　控制複雜度：生活中通常將複雜大問題劃分為若干個容易解決的小問題。DDD的戰略工具“子域”就是控制複雜度的工具：核心域，通用域，支援域就是劃整體為部分，降低複雜度的具體方式。

　　提升複用性：DDD子域型別裡"通用域"的概念，清晰表明域的可複用性。

　　域劃分的設計原則，我的觀點是：非必要不劃分；無收益不劃分；不確定不劃分。域劃分一定要有收益：要麼是複雜度降低；要麼是複用性提升；要麼兩者都有。如果沒有收益或收益過少，就不要劃分子域。在實踐中域劃分錯誤的兩種"壞味道"：

　　域很淺: 域劃分很細，每個域少數幾個物件，通常是問題不復雜，不需要劃分。

　　域邊界模糊：領域物件關係複雜，子域間沒有清晰邊界，暗示了模型關係錯誤或者子域劃分錯誤。

　　域的識別

　　雖然有很多的方法幫助識別子域，最主要的還是靠實踐摸索，從正反兩個方向迭代設計：

　　正方向：從各種特徵/方法出發識別可能的域 (域劃分包括：從域定義出發/參考已有標準方案/識別領域概念模糊性/四色建模/事件風暴等）；

　　反方向：透過域設計原則和收益驗證劃分的合理性；

　　域的驗證

　　域設計原則以星環總結的"自治單元"最為完備，實操性較好。　　

　　領域自治與設計原則高內聚低耦合是一致的，核心判斷點：

　　最小完備&自我履行 看 "依賴" : 域的價值主張決定了域職責，域內包含了完成職責所需要的必要資訊以及能獨立作出決策，不/少依賴外部域。舉例來說：在業務系統設計裡經常看到執行域和配置域的設計；執行域執行任何功能都依賴配置域資訊。那麼從域的完備性和自我履行角度考慮，這種拆分是不合適的。

　　穩定空間&獨立進化 看 "變化"：穩定空間是當前域不受/少受外部域變化的影響；獨立進化是指域內變化對外部域沒有影響/影響較小。舉例來說，子域A直接引用了子域B的領域物件C，物件C變化一定影響到子域A；這種情況說明領域A不夠穩定；或者說領域B不能保持獨立進化。

　　流程建模

　　流程設計問題

　　以DDD四層模式為例：領域層模型設計逐漸得到了重視；但是應用層設計沒有得到足夠重視。通常講應用層職責是面向用例組織業務流程，在實際程式碼實現中能發現非常多的應用層混亂導致的程式碼複雜度提升，典型問題包括：階段粒度不一；節點職責不清；互動混亂。出現這些問題根源是業務邏輯是圍繞“資料中心”組織的，沒有對流程進行仔細的設計和組織。　　

　　流程建模做什麼

　　這裡的“流程建模”特指業務邏輯處理的組織方式。流程建模三件事： 定階段，定職責，定互動。

　　定階段

　　這裡的“階段”和"流程節點/處理節點”等概念類似，定階段就是設計業務場景下程式處理步驟，包含業務和技術考慮。階段是設計出來的傳達出的觀點是：根據設計目的（效能/靈活性/結構清晰等)，階段的粒度/順序是有選擇空間。注意：同型別流程的階段劃分粒度保持一致。同型別理解為類似場景，舉例來說訊息處理場景，那麼不同型別訊息（建立/完結/撤銷等）的處理流程的階段粒度保持一致。

　　定職責

　　定義每個階段的職責範圍。在設計裡（無論域識別/應用分層等粗粒度還是類/方法等細粒度設計），職責定義都很重要：明確了職責本質上定義了邊界。這樣每種功能的實現位置做好了設計，減少了隨意性，有利於架構整體的清晰性，不至於腐化成大泥球。

　　定互動

　　流程間&流程內的呼叫關係。請看下圖示例的執行過程（這是從真實程式碼還原出來的）：節點A呼叫了擴充套件點，擴充套件點執行完成後呼叫了節點B. 大家先想一想這樣合理嗎？　　

　　在生活中同層級機構對話、機構內上下交流、機構間同職級交流；很少有低層級員工直接和外部機構的領導對話。這是我們的生活經驗，流程互動設計的原則也是類似的，節點負責組織該階段內的執行邏輯，完成後通知下一個節點。這種節點互動原則總結為：階段內上下對話，階段間水平對話。　　

　　流程建模怎麼做

　　自下而上流程建模簡化為窮舉->歸納->推演三步驟，每一步都可以若干次迭代完善。

　　窮舉: 選擇熟練的工具梳理流程（流程圖，ES等都可以），建議是：按業務場景型別梳理，一次可以梳理一個或幾個場景，分多次完成。

　　歸納："通看"場景，找共性、找差異、找設計點，採用"合，增，調"(合併同類節點；增加缺失節點；調整節點順序)三技巧完成流程設計。如何“調順序"要看設計目的，例如效能優先將部分業務校驗節點調整到前面。

　　推演：用步驟2設計的流程推演業務，主要評估執行順序和節點職責是滿足業務需求。　　

　　例項練習

　　自下而上流程建模

　　使用自下而上方法為員工入職跟蹤流程建模：首先由HR錄入待入職員工個人資訊和資料，確認無誤後為員工分配辦公空間；隨後系統為員工準備資產和開通賬號&許可權；員工領取到資產，登入賬號後，入職流程就完成了

　　第一步 自下而上做歸納

　　由上文的價值流熱力圖，我們知道公司的入職跟蹤流程亟待建設：入職跟蹤和員工資訊管理能力缺乏；資產管理&設施管理&安全管理有基礎能力，但是需要提升。本次使用了事件風暴方法，業務，產品和研發一起梳理入職跟蹤過程，目的是建設入職跟蹤能力。　　

　　第二步 抽象分析出設計

　　員工入職跟蹤接收來自資訊管理系統，資產管理系統，安全管理系統的事件，更新入職進展。設計後的流程模型如下圖。增加了技術節點: 訊息解析，校驗，協議適配；為保持流程清晰性，將判斷是否"首次流入"的節點提前到了協議適配前執行。　　

　　第三步 自上而下驗場景

　　推演是將業務執行過程，用流程表達出來；場景推演技術特別適合複雜業務的驗證，能發現設計階段的遺漏點。下圖推演員工已報到事件的處理流程。　　

　　總結

　　本文提供一種業務架構設計模式供大家參考。整個框架希望表達2個重點：1 首先要有業務視角思考，突破僅關注需求實現設計，而是從業務價值出發的業務架構思維；2. 強調設計的邏輯：自上而下或自上而下都是強調設計過程，每個設計決策需要經過推演得出。