什么是體系化？為什么要體系化架構(gòu)
寫在前面
為什么要聊體系化？最重要的一個原因是“卷”。
假期和朋友聊天，說我們在搞“產(chǎn)品體系化解決方案”，究竟怎么搞呢？不知道。
我說“你們不是才搞完產(chǎn)品領域化嗎？怎么又搞新的？產(chǎn)品領域化有什么收益嗎？”
他說老板給到他的就是一個命題作文，“把咱們產(chǎn)品體系下的技術(shù)、系統(tǒng)、概念以體系化方式呈現(xiàn)，也就是“產(chǎn)品體系化””。
之前的文章中我們提到過目標和問題的重要性，做任何事都要師出有名，所有的目標圍繞于解決什么問題？或一個目標？體系化的背后究竟有什么痛點、難點？老板也沒想明白，只是甩給了他這個命題作文。
看這不是“內(nèi)卷”了嗎？
大廠內(nèi)卷的一個重要的參照物就是“開始輸出概念了”，之前和阿里老員工聊，說：“你們阿里現(xiàn)在輸出的概念比解決的問題多啊”，他說：“不輸出概念怎么晉升？”。第一年ppt內(nèi)容是“xxx數(shù)字化”第二年變成了“xxx數(shù)智化”，方案差不多，概念先占一個。
卷也有卷的道理，如果你老板給你一個這樣沒有明確目標的命題作文你會怎么搞？不知道。
但是嘗試聊聊，說不定哪天用到了。
體系化思維
為什么需要體系化思維？
日常工作中，我們面對的問題是散亂的、非結(jié)構(gòu)化的，問題不夠聚集，導致我們的解決問題的效率不高，產(chǎn)出也不夠清晰。
所以我們需要在工作中找到主線，將面對的問題有條理的梳理出來就非常重要。
一般怎么梳理呢？
可以針對復雜問題，列出關鍵要素和解決方法，將散亂無序的問題變得有邏輯可循。
完整的體系化思維包括：明確目標、拆解問題、細化方案、執(zhí)行落地、閉環(huán)總結(jié)、項目迭代等幾個核心環(huán)節(jié)。
通過以上體系化思維，可以幫助我們基于現(xiàn)狀、問題、目標產(chǎn)出一套高效優(yōu)化工作效率的框架思維。
明確的目標是做好體系化的第一步，目標是全局動作的驅(qū)動力，展開的一些動作都是服務于這個目標。
拆解問題可以幫助我們直面問題，直面解決過程。不僅著眼于目標，更多是帶入解決問題的情境中去思考解決方案。
細化方案是羅列出針對于每個問題的解決方案，方案的細化要保證具備極強的操作性和可衡量性，以便在方案落地過程中和后期評估方案的效果。
執(zhí)行落地是協(xié)調(diào)資源落地的過程，執(zhí)行過程中溝通必不可少，良好的溝通可以更有力的推動工作開展，保持團隊內(nèi)信息高度一致，明確進度和人員定位，事半功倍。
閉環(huán)總結(jié)可以從三方面展開：數(shù)據(jù)效果總結(jié)、方案流程總結(jié)、溝通執(zhí)行總結(jié)。前兩個是針對于工作過程的總結(jié)，重視處理專業(yè)問題的能力和方法。后者針對的是團隊成員“人”的總結(jié)，重視個人發(fā)展和團隊培養(yǎng)軟實力。
項目迭代是讓項目進入新階段、新高度的起點，在一個新的環(huán)境下重新回到第一個階段，明確新的目標，開始新一輪的增長。
所以體系化思維是一種整合全局業(yè)務流的思維，通過適當?shù)?strong>分解工作內(nèi)容，梳理工作環(huán)節(jié)之間的內(nèi)在聯(lián)系，搭建完善的體系化框架，來保障工作持續(xù)高效運行，創(chuàng)造價值。
怎么將體系化和技術(shù)結(jié)合起來呢？
體系化講的是流程、分解、組織、搭建框架這些東西，那我們做技術(shù)過程中有哪些是需要分解、再組織、以框架方式整合的呢？
盡管我們在工程實現(xiàn)之前分析時，有各種框架（Spring、MVC），采用了各種模式、模型（DDD、SOA、微服務）。但落地過程中避免不了業(yè)務邏輯分散在各個系統(tǒng)當中，出現(xiàn)各種跨module、跨服務的隱式耦合。這種分散勢必造成應用架構(gòu)的割裂，如果沒有持續(xù)的重構(gòu)與調(diào)整，最終會變得復雜臃腫。
究竟什么原因?qū)е逻@種情況的呢？
盡管我們有各種工程框架、研發(fā)規(guī)范，但這種約束過于靈活，也更過于“技術(shù)化”。缺少以業(yè)務視角進行設計規(guī)范，也就導致了同樣類似的方案最后實現(xiàn)上過于差異。
早期項目開始之時，由于需求背景較為清晰，業(yè)務復雜度不高，系統(tǒng)、模塊在設計與實現(xiàn)上有比較明晰的邊界，隨著業(yè)務的發(fā)展，系統(tǒng)冗雜了過多新業(yè)務代碼、適配業(yè)務代碼，而且每個階段功能實現(xiàn)人的設計思維不同，同時系統(tǒng)架構(gòu)缺少約束力，導致架構(gòu)實現(xiàn)的復雜度變高，開始腐化。
用曾經(jīng)的架構(gòu)來設計當前的業(yè)務場景，但可能引入大量額外的成本，喪失了原本設計的優(yōu)勢，后期需要做大量的減法。
喜歡造輪子而不是持續(xù)對輪子重構(gòu)，研發(fā)同學有潔癖“玄學”，編碼風格各領風騷，往往對前人設計“重構(gòu)”更來得快些。
靠文檔傳承而非工具復用，很多新人說老人留下的文檔太少了，建議提供標準、準確的需求文檔及數(shù)據(jù)庫設計詳細er圖，還有些團隊為了搞“降本增效”，強推API DOC，然而并沒有卵用，歸根接地的問題在于，研發(fā)工程師沒有“義務”去持續(xù)優(yōu)化這個DOC，國外軟件公司，如微軟其實是有專門的api文檔團隊的，國內(nèi)公司基本沒有，所以在文檔交接這塊不要期望研發(fā)可以多做一步。
為解決以上問題，就會想，在業(yè)務架構(gòu)實現(xiàn)過程中，除了具體技術(shù)實現(xiàn)之外，有沒有一些業(yè)務維度的普世價值觀在業(yè)務架構(gòu)設計領域或某個領域內(nèi)，建立一套面向業(yè)務研發(fā)同學的“設計規(guī)約”呢？
幾個關鍵詞：
標準：統(tǒng)一業(yè)務設計框架，用標準化架構(gòu)簡化技術(shù)細節(jié)
沉淀：從業(yè)務場景中持續(xù)沉淀積木、輪子、組件
重構(gòu)：持續(xù)重構(gòu)積木，減少重復建設
集成：基于業(yè)務服務編排引擎快速集成
標準
標準的本質(zhì)在于減少細節(jié)，理想狀態(tài)下，業(yè)務研發(fā)只需要關注于領域建模，但真實落地過程中不得不考慮很多通用技術(shù)的實現(xiàn)細節(jié)，比如供應鏈金融場景下應收賬款流程：
領域建模：應收賬款領域模型及其行為的設計
流程編排：流程模型的設計及發(fā)行流程的狀態(tài)機設計
數(shù)據(jù)轉(zhuǎn)換：領域模型 -> 數(shù)據(jù)模型及流程模型-> 數(shù)據(jù)模型的雙向轉(zhuǎn)換
并發(fā)控制：業(yè)務鎖機制設計
業(yè)務冪等：流程中各業(yè)務環(huán)節(jié)的冪等控制
異常處理：異常捕捉，錯誤碼約定
監(jiān)控報警：摘要日志，異常日志，邊界日志
其他
看下來，除了“領域建模”之外都是和基本的業(yè)務無關的，但同時也是不可或缺的。所以需要一套標準化的框架方案，以統(tǒng)一的規(guī)范解決掉業(yè)務無關的大量細節(jié)，讓業(yè)務研發(fā)同學專注“領域建模”。
沉淀
沉淀的本質(zhì)在于能力復用，能力復用不局限于形式和粒度，以降低技術(shù)成本為核心，提高業(yè)務擴展性，就可以看做是滿足了沉淀的目標。所有沉淀下來的東西都可以作為組件為后期復用。
沉淀的組件包括：技術(shù)類、業(yè)務類、平臺類。
技術(shù)類：
工程規(guī)范：約束編碼規(guī)范和邊界接口定義風格，日志打印、異常處理、倉儲行為、狀態(tài)機等。
讀寫分離：屏蔽交易類需求與查詢類需求對接數(shù)據(jù)庫模型的差異，降低設計復雜度、提高查詢性能和靈活性。
業(yè)務類：
網(wǎng)銀核身：提高網(wǎng)銀核身簽名在不同業(yè)務流程中的擴展性
合約上鏈：提高智能合約對接在不同業(yè)務流程中的擴展性
平臺類：
配置中心：靈活定義和管理業(yè)務流程需要的各類配置項
產(chǎn)品中心：平臺功能打包和隔離，實現(xiàn)業(yè)務流程全局視圖
重構(gòu)
重構(gòu)的本質(zhì)在于持續(xù)優(yōu)化，我們基于歷史的業(yè)務理解沉淀下業(yè)務需求，但很難直接適用于新的業(yè)務場景下。這也是后來人很難復用千人設計出來輪子的原因。這也是很多團隊說在做沉淀，但可以在橫向復用或持續(xù)輸出的可復用的輪子少之又少，看起來沒有完美的解法，但我們對于一個好的可復用的輪子是有標準的。
集成
集成的本質(zhì)在于靈活搭建，為保障標準化的落地，有了可復用的輪子之外，還需要有靈活的粘合劑，這樣才能真正實現(xiàn)靈活、快速的搭建與調(diào)整。
在很多業(yè)務場景下，業(yè)務需求主要體現(xiàn)為支持各種各樣的業(yè)務流程，為簡化積木搭建，靈活復用底層能力，可以設計面向業(yè)務的服務編排引擎：
標準化：遵循設計規(guī)約，將業(yè)務無關的通用技術(shù)細節(jié)屏蔽
插件化：對輪子友好，可持續(xù)沉淀和復用新能力
業(yè)務化：面向業(yè)務，有業(yè)務描述能力的流程編排
配置化：通過配置即可完成流程編排，最好可以做到可視化編排
產(chǎn)品
技術(shù)是服務于業(yè)務的，為實現(xiàn)全流程承接，我們需要業(yè)務大圖。以輪子+粘合劑可以滿足技術(shù)落地的低成本的高擴展性，在結(jié)合業(yè)務大圖來描繪業(yè)務線的全域能力和功能流程。
有了這么多概念，是不是還不知道怎么做？
那我們看下善造概念的阿里同學是怎么做的。
業(yè)務架構(gòu)標準方案
整體解決方案我們稱為：業(yè)務架構(gòu)標準方案。
前面說了只靠文檔形成的共識，對技術(shù)是沒有約束力的。于是我們不期望建立一整套全局業(yè)務大圖下的API DOC，而是通過組件化工具的方式約束業(yè)務應用，形成團隊共識，生成一套標準化的業(yè)務架構(gòu)設計方案。
標準的業(yè)務應用架構(gòu)如下：
組件：規(guī)范技術(shù)實現(xiàn)細節(jié)
通過組件化約定，約束通用技術(shù)細節(jié)行為，如：
交易模型：描述了業(yè)務流程的核心交易模型，用于管控狀態(tài)推進，維持與業(yè)務模型的關聯(lián)。
倉儲模型：數(shù)據(jù)持久層的通用行為收斂，包括鎖定查詢、數(shù)據(jù)的插入、更新、通用查詢等。
事務模板：定義事務邊界，確保模板域內(nèi)業(yè)務邏輯的事務一致性，支持冪等。
通用業(yè)務模板：定義業(yè)務邏輯的邊界，無事務性保障，包含基本的異常處理、日志埋點等通用功能。
通用查詢模板：定義查詢邏輯邊界，與通用業(yè)務模板類似，但主要面向單向、批量、分頁等查詢場景。
消息：對消息中間件的簡單封裝，適配業(yè)務應用規(guī)約，降低配置成本。
調(diào)度：對調(diào)度中間件的簡單封裝，適配業(yè)務應用規(guī)約，降低配置成本。
服務開放：api組件規(guī)范對域外服務能力的銜接，通過注解識別服務定義和服務實現(xiàn)，自動生成接口文檔，通過描述接口參數(shù)、返回、業(yè)務域、錯誤碼等。
其他還包括：日志、異常處理、請求參數(shù)、返回類型等技術(shù)細節(jié)。
上面是所有業(yè)務應用都會遇到的技術(shù)細節(jié)，用組件屏蔽細節(jié)的思路將技術(shù)復雜度封裝起來，我們邏輯重點在于：盡可能沉淀和復用技術(shù)組件，不重復搭建，將研發(fā)重新放到業(yè)務上。
領域：專注業(yè)務建模
技術(shù)是服務于業(yè)務的，相信每一個從事業(yè)務架構(gòu)研發(fā)同學都深知這一點。而業(yè)務以建模為核心，所以在整個研發(fā)流程中，我們最應該持續(xù)投入的就是業(yè)務研發(fā)階段，直面核心業(yè)務設計與思考，應該讓研發(fā)同學從其他研發(fā)環(huán)節(jié)中釋放出來。
那如何基于領域建模實現(xiàn)領域產(chǎn)出呢？
領域?qū)嶓w：建模的核心是抽象出領域?qū)嶓w和其關聯(lián)關系，不同業(yè)務場景下設計思路不同，最終體現(xiàn)為一到多個領域模型。
領域倉儲：定于數(shù)據(jù)模型及其領域模型之間的對應關系，通過上面提到的倉儲組件，配置數(shù)據(jù)庫表和連接，實現(xiàn)鎖定查詢、CRUD等通用業(yè)務行為。
領域服務：基于業(yè)務行為，抽象出原子化領域服務能力，領域服務無需關注數(shù)據(jù)倉儲及業(yè)務流程，僅抽象出領域?qū)嶓w的原子能力即可。
交易實體：用于承載交易流程的業(yè)務實體，內(nèi)部關聯(lián)一到多個領域?qū)嶓w。
交易倉儲：用于管控交易實體及內(nèi)部領域?qū)嶓w的倉儲行為。
服務編排引擎：組件+粘合劑
但凡涉及到復雜業(yè)務流程的應用，都需要引入流程引擎來編排狀態(tài)機流轉(zhuǎn)。業(yè)界很多成熟的流程框架，存在普遍的問題就是：過于靈活，難以約束設計，大量業(yè)務細節(jié)分散在不同狀態(tài)節(jié)點之間，不直觀也難以維護。
所以需要一套面向業(yè)務的服務編排引擎，以遵循業(yè)務設計規(guī)約的方式約束技術(shù)，以直觀的形式描述業(yè)務流程：
約束業(yè)務模型：需明確指定業(yè)務交易模型、狀態(tài)、倉儲定義，遵循業(yè)務設計規(guī)范
托管倉儲行為：只需要配置業(yè)務模型及倉儲實現(xiàn)，無需關注數(shù)據(jù)持久化細節(jié)
編排領域服務：通過轉(zhuǎn)換層，將領域服務開放到引擎中自由編排。領域的原子能力是引擎編排的最小執(zhí)行單位
靈活增減狀態(tài)：流程中狀態(tài)遷轉(zhuǎn)和業(yè)務行為均可靈活拔插
支持輪子擴展：將可復用的領域服務組合打包，形成固定模式，作為輪子在其他流程中復用
總的來說，組件是屏蔽具體技術(shù)細節(jié)，服務編排引擎基于組件的編排，屏蔽更多的技術(shù)細節(jié)，復用價值也就更大，編排出更符合業(yè)務需求的業(yè)務流程。
總結(jié)
通過體系化技術(shù)框架，讓技術(shù)團隊從現(xiàn)實痛點觸發(fā)，以業(yè)務架構(gòu)設計規(guī)約（研發(fā)標準）結(jié)合業(yè)務架構(gòu)標準（工程約束）來統(tǒng)一團隊的技術(shù)風格，將研發(fā)同學從細節(jié)中釋放出來，專注于技術(shù)能力的積累和業(yè)務價值的思考。
實現(xiàn)細節(jié)包括：
標準約束技術(shù)細節(jié)：降低業(yè)務設計靈活性，降低成本
用技術(shù)工具而不是API DOC推行標準：持續(xù)沉淀組件，勝過沒有約束力的文檔
持續(xù)重構(gòu)而不是重復造輪子：正式團隊輸出，持續(xù)帶來價值
重視業(yè)務建模：圍繞于業(yè)務以DDD實現(xiàn)落地，提升建模思維和能力