引言
在上一篇文章中主要講了業務架構的基礎部分，整體的業務架構還有一些其它點要考慮，如業務之間的彼此隔離、業務與技術(平臺)的隔離、業務能力地圖的可視化、業務mock能力、業務監控等，本篇文章主要講述這些內容。
一、業務彼此隔離
在較小的公司可能要體現這個沒有對應的業務場景，但在大公司中，如果業務是平臺型的，承接的業務方較多，業務方之間的需求還不一樣時，就體現出了業務與業務之間的隔離。比如，優惠券業務是平臺型業務，有多個業務線的業務方接入，它們的訴求也不盡相同：有的要實現業務線內不同用戶角色的打通(乘客、司機等)、業務線之間風控策略也不一樣、優惠券發放規則也不一樣…
業務與業務的隔離需要有一個標識來唯一標誌，阿里有的團隊叫bizId，在我們團隊是通過productId(業務線Id)來區分。標識說起來簡單，但它只是第一步，隔離的表象就是通過業務線來區分。思考一個問題爲什麼要實現業務之間的彼此隔離？
- 業務自身需求：這個很好理解，不同的業務有自己的特點。
- 業務之間的互不影響：隔離的目的就是爲了互不影響，將變化的東西縮小到業務線內，不可能改動一個業務線的需求，結果把其它業務線影響了。
- 業務的可擴展性：平臺型的業務有一個最大的特點是要較好地支持可擴展性，往大的方面講，新接入一條業務線的改動有多大、往小的方面講，對於某個業務線內的需求改動又是多大，比較好的狀態就是具備可配置，稍微配置一下，一個新業務線就接入，這是我們最想看到的結果。
通過productId(業務線Id)這個唯一的業務身份串起整體業務，在業務處理過程中，可以知道這個業務線需要的具體業務策略和處理規則。
結論一：業務與業務的隔離體現了業務之間的變化和獨立性，所以就產生了業務與技術(平臺)的隔離。
二、業務與技術(平臺)的隔離
業務與技術(平臺)的隔離體現了變與不變的關係，雖然這句話被很多人講過，但不同的系統實現的策略不一樣。平臺型業務一般要解決80%以上的共性問題，20%左右通過開放來實現。
業務與技術(平臺)的隔離不像業務與業務之間的隔離那樣，兩個業務之間沒有交集，業務與技術(平臺)之間是有交集的，這讓人聽起來有些蒙，下面細細分析。
-
不同業務線之間有一條共性的業務流程：雖然不同的業務線產品之間有各自不同的點，但它們之間有一個明顯共性的業務流程，這個業務流程是業務的生命週期，就好比類與對象之間的關係，本質是同一類事物，不同的對象好比不同的業務線產品，具體的實現上有些差異。在優惠券中，核心的業務流程就四個：建券、發券、用券、退券，不管什麼業務線接入，它都遵守這條固定流程。
-
業務變化的是子流程中的內容：不同業務線產品的不同之處體現在哪裏？體現在業務細節上，這個是變化的，如業務的准入條件不一樣、業務規則不一樣、有的子流程中某一個處理步驟不需要…，這些是變化的部分，需要把變化的部分抽象出來並封裝變化。所以，不變的是業務大流程，變化的是業務實現細節。
-
業務與技術(平臺)的隔離理解的二重性：有些人理解業務與技術(平臺)的隔離就是業務的實現不依賴於技術，比如數據要怎樣存儲？服務治理用什麼框架？…這些說的是對的，它本身沒有錯。而我理解是有兩重含義：一就是如上面所說的，業務的實現不依賴於具體技術，偏技術選型，這是常識；二是領域層的可擴展性，前2項已經說了業務的共性和變化，這個就是體現出應對變化的策略，儘管不同的系統有不同的具體實現，但總的原則是平臺要能識別出這些變化，並能應對這些變化。
業務與技術(平臺)的隔離體現在共性和變化的隔離，把變化的部分告知平臺、實現開放出來，所以說它們是有一定交集，這個交集就是應對變化的部分。它涉及到技術方面，所以在技術架構中會單獨拿一篇來講。
結論二：業務與技術(平臺)的隔離主要體現在處理業務的變與不變。
三、業務能力地圖
我們有一個體會是開發和產品有時在談一個需求時，開發用開發的語言、產品用產品的語言，兩個很難統一，雖然通過領域建模可以統一認識，但是隨着時間的推進，人員結構也在不斷變化，如何快速熟悉業務、統一業務認識是一個問題。
發現通過業務能力地圖來表示業務流程，可以減少溝通、統一認識、可視化表示業務產品功能所經過的關鍵業務路徑，這樣一個新人進來通過這個業務能力地圖就可以知道業務的主流程是什麼，產品功能涉及到哪些業務子流程，針對一個需求，開發不需要看代碼哪裏要修改，很直觀地在業務能力地圖可以知道本次需求涉及到的改動點，從而提升整體效率。
在做業務能力地圖之前是有條件的，否則只是一家之言，有什麼意思呢？就是業務已經進行了領域建模，業務產品和開發達成了統一的認識，業務的領域對象有哪些、業務的主流程、子流程有哪些、業務的准入條件、規則判斷等，只有這些大家已經統一認識了之後，再通過技術手段把這些信息可視化表示出來就行，否則只會站在開發的角度來理解要表示哪些流程步驟。換言之，業務能力地圖中所展示出的節點信息都是開發、產品統一的語言。
業務能力地圖是領域模型的進一步擴展和延伸，領域模型偏靜態的表達領域對象和領域對象之間的關聯關係；而業務能力地圖是動態的表達業務執行流程是什麼。領域模型是基礎，業務能力地圖是進一步的擴展，一個表達有什麼，一個表達怎麼做，一動一靜，可以更好的理解業務和業務流程所涉及到的核心步驟。
結論三：業務能力地圖是在領域模型的基礎之上進一步擴展，可視化地表達業務流程。
四、業務mock能力
業務mock能力是指mock用戶數據方便排查問題，排查問題的第一步是重現問題，尤其是在端上，可能在某些條件下展示有問題，用測試數據又沒有重現這個問題，如何來做呢？可以通過mock用戶的信息來展示數據，說白了就一句話偷天換月，在最底層的查詢時，把用戶信息置換掉。舉個例子，用戶在下單時發現有些優惠券沒有展示在列表頁中(實際上是有些優惠券不滿足訂單條件，如滿減券、限門店使用等)，用戶向客服反映，客服再向技術支持人員反饋，技術支持人員再往具體的開發反饋，這個鏈路就很長了。如果客服同學使用這項mock能力，完全可以通過mock用戶數據來當前的數據是怎麼展示的，再看用戶所有優惠券，對比優惠券的限制規則就能知道哪些優惠券不能使用，這樣就可以快速響應用戶問題。
使用這個mock能力時，有一點需要考慮的就是數據安全，並不是所有的行爲都可以mock，一般來講只有讀場景下才能mock；還有一點需要注意的是全鏈路mock範圍，只有在指定的接口上才能mock，不能直接從導購鏈路一路往下mock，只會在最底層的業務接口上進行mock，否則全鏈路數據都被置換了。
結論四：mock主要方便問題重現和定位。
五、業務監控
業務監控也是非常重要的一個環節，不同的公司用的方法也不盡相同，也要看業務規模和公司的實際情況，不可能要求所有的公司都使用大數據來分析。根據自己的經歷談談這塊。
小公司直接統計業務數據表，比如之前做過金融，根據還款數據拆分成還款計劃，還款計劃再生成對應的還款訂單，這裏面的涉及到的業務數據就比較多，但能夠很好地進行監控，當時根據業務數據狀態、數量來判斷業務是否已經處理完了，通過覈對數據看今天的業務執行是不是正確的。這雖然很簡單，通過寫SQL+定時執行shell腳本就可以搞定，在業務的初創期它最簡單，關鍵是提煉出監控的指標和維度。
在大公司，通過日誌採集、清洗、實時統計，可以看出當前業務的處理情況，有同比、環節的數據，如當前下單率是多少，通過監控這個指標可以看出業務是否正常，如果下單率明顯下跌比較厲害，大概率是哪個鏈路上出了問題。
通過業務監控大盤分別從不同的維度來監控業務運行狀況，從而可以分析判斷出當前業務是否受影響，幫助開發人員提前發現問題，這一塊也涉及到穩定性方面，大公司是非常重視這一塊的，阿里雙11會專門成立穩定性小組，穩定壓倒一切。
結論五：沒有業務監控的系統對業務的運行狀況一無所知。
六、小結
本篇文章是在上一篇文章的基礎之上，對業務架構進一步補充，在平臺型的業務中，着重注意業務與業務的隔離、業務與平臺的隔離，實現最少的投入實現最大的業務價值。後面提到的業務能力地圖、業務mock能力和業務監控是從工具層面上統一人員認識、提升溝通效率、快速發現、復現問題。接下來的系列就是技術架構了，從技術的角度解決常見的問題，如高併發、高可用、穩定性、高可擴展等。
作者簡介
高福來，先後在Oracle、阿里工作，目前在滴滴小桔車服加油團隊負責營銷基礎(優惠券、獎勵金)，在分佈式中間件和系統架構方面積累了一定的經驗，擅長用通俗易懂的語言描述複雜問題。
相關文章：
《系統架構系列（一）：如何用公式定義該概念？》
《系統架構系列 (二)：應對這一概念的方法》
《系統架構系列 (三)：業務架構實戰上篇》