背景介紹

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

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

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

業(yè)務架構

業(yè)務架構目的

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

業(yè)務架構做什么

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

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

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

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

業(yè)務架構怎么做

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

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

業(yè)務能力:?業(yè)務能力是業(yè)務為實現(xiàn)特定目的或結果而可能擁有或交換的特定能力或產能

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

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

理清楚人&責-角色分析

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

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

應用架構

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

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

• DDD：子域就是組件，域之間的關系，域設計原則

• 流程視角：流程，子流程，階段都是組件；定義不同粒度下組件的交互關系和原則

• 數(shù)據(jù)視角：數(shù)據(jù)表是組件，表之間的關系，和設計原則（范式和反范式）

• 架構分層：層是組件，分層交互的關系和原則

• ....

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

架構方法

自上而下

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

自下而上

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

自下而上"三板斧"

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

第一招：自下而上做歸納

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

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

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

• • 先根據(jù)經驗或直覺選主要的劃分維度，識別類型

  • 將場景歸入對應分類

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

第二招：抽象分析出設計

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

第三招：自上而下驗場景

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

架構實踐

領域建模

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

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

域的目的

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

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

• 提升復用性：DDD子域類型里"通用域"的概念，清晰表明域的可復用性。

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

• 域很淺:?域劃分很細，每個域少數(shù)幾個對象，通常是問題不復雜，不需要劃分。

• 域邊界模糊：領域對象關系復雜，子域間沒有清晰邊界，暗示了模型關系錯誤或者子域劃分錯誤。

域的識別

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

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

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

域的驗證

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

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

• 最小完備&自我履行?看?"依賴"?: 域的價值主張決定了域職責，域內包含了完成職責所需要的必要信息以及能獨立作出決策，不/少依賴外部域。舉例來說：在業(yè)務系統(tǒng)設計里經?？吹竭\行域和配置域的設計；運行域執(zhí)行任何功能都依賴配置域信息。那么從域的完備性和自我履行角度考慮，這種拆分是不合適的。

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

流程建模

流程設計問題

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

流程建模做什么

這里的“流程建模”特指業(yè)務邏輯處理的組織方式。流程建模三件事：?定階段，定職責，定交互。

• 定階段

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

• 定職責

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

• 定交互

流程間&流程內的調用關系。請看下圖示例的執(zhí)行過程（這是從真實代碼還原出來的）：節(jié)點A調用了擴展點，擴展點執(zhí)行完成后調用了節(jié)點B. 大家先想一想這樣合理嗎？

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

流程建模怎么做

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

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

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

• 推演：用步驟2設計的流程推演業(yè)務，主要評估執(zhí)行順序和節(jié)點職責是滿足業(yè)務需求。

實例練習

自下而上流程建模

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

• 第一步 自下而上做歸納

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

• 第二步 抽象分析出設計

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

• 第三步 自上而下驗場景

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

總結

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

以上即是本文提供一種業(yè)務架構設計模式：從業(yè)務&技術兩個角度提煉出一個基礎思維框架，供業(yè)務線開發(fā)同學參考。文章來源地址http://www.zghlxwxcb.cn/news/detail-494293.html

到了這里，關于業(yè)務架構設計模式的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！