如果第二次看到我的文章，歡迎右側掃碼訂閱我喲~ 👉
每週五早8點 按時送達。當然了，也會時不時加個餐～
在一個分佈式系統的開發團隊中，有一些問題是很容易產生程序員之間矛盾的。
其中之一就是「業務歸屬」，就是當新加/修改一個業務的時候，代碼變更應該放到你負責的系統還是我負責的系統裏？
一些業務輪廓很清晰的就不用說了，大家的認定都是一樣的。比如商品相關的放到商品服務，會員相關的放到會員服務。
但是對於輪廓模糊的業務，大家作出的決定就不一定相同了。
這個時候起決定性作用的並不是各自的工作經驗，而是你的「業務思維」是否具有全局性，以及對全局業務的瞭解程度如何。
一旦草率的作出了“不合適”的歸屬劃定，後續將會帶來大量的額外成本，協作、更高的bug率等等。
看看以下的場景是不是平時有見到過？
-
嗨，小明，我這裏有個bug需要你和我一起調試下。
-
當初如果這個業務在這裏就好了，現在已經積重難返了，只能推倒重做了。
-
我覺得這個問題可能是這裏導致的，也有可能是那裏導致的。
所以，一個業務歸屬於哪個項目，看似是一個很簡單的選擇題。但是每個人心中的默認選擇是不同的，比如以下兩種截然不同的傾向。
-
我能解決的就我解決咯，實在解決不了的再給對方
-
只能我這裏解決的就我這裏解決，其它的全部對方來
其實這些選擇都是因人而異的，很難形成一個放之四海而皆準的共識。
如果雙方都選擇第二點，產生衝突、爭執是必然的。
哪怕大家都選擇“爲他人着想“的第一點，只是避免了相互扯皮，但還是無法避免後續業務邊界混亂付出的額外成本。
所以，我們還是需要從中提煉出本質的東西作爲決策的準則。
Z哥我認爲思考業務歸屬的時候，本質上還是逃不開「高內聚低耦合」範圍，一個合理的項目歸屬認定，會讓軟件系統離每個人所期望的「高內聚低耦合」更近一步。
因爲「業務歸屬」和「高內聚低耦合」一樣，都在“劃線”，明確邊界。
但是我們很多時候其實並不知道“線”應該具體畫在什麼位置，只是知道一個大概方位而已。
其實，如果當我們的系統只是一個單體應用的話，是不存在「業務歸屬」問題的。
因此它是在分工協作下所產生的一個副作用。
但是，只要我們繼續保持分工協作來開發一個分佈式系統，這個問題就是繞不開的一道坎。
在工作中，由於邊界不清容易產生業務歸屬分歧的場景主要是以下兩點。
-
一個新業務，需要兩邊配合完成
-
一個老業務，一部分在A處理，一部分在B處理。
這裏先停頓一分鐘，想一想，如果是你的話，該如何來作出選擇？
Z哥我給你的建議是，你可以這樣來考慮：哪邊缺了這個業務的話，會導致至少一個流程走不通。
來舉兩個例子幫助你理解。
一個電商網站現在要上線一個會員卡的功能，類似阿里的88會員這種。
效果是買了這個會員卡的用戶，在該平臺購買自營商品時，享受8折優惠。
那麼你來思考一下？這個業務到底是放到「會員服務」還是「促銷服務」？
參照上面的建議來思考就是回答兩個問題：
-
會員服務缺少了這個會員卡業務，是否有至少一個流程走不通？
-
促銷服務缺少了這個會員卡業務，是否有至少一個流程走不通？
很顯然，會員卡雖然有一個打折功能，但是這個打折是建立在一個身份標識上的。
那麼就要思考一下，這個身份標識後續是否會在整個購物鏈路中的多個環節有露出展示或者對應的專屬業務，比如專屬客服、每月領福利等等。
另外你會發現，如果促銷想實現打8折的效果，可以完全不需要有會員卡的存在也能做到。
所以，這個會員卡本質更像是會員屬性的一個擴展，是跟着某個具體的會員走的。
假如最終不小心被歸屬到了促銷服務，則每次圍繞會員卡展開的業務都需要與促銷服務產生耦合才能完成，很明顯就背離了「高內聚低耦合」的初衷。
所以，對促銷服務來說，會員卡業務並不是必不可少的。相對來說，會員服務與它的關係更緊密。
至此，第一個例子的答案就出來了，應該放到會員服務。
再來看第二個例子。
隨着社交電商模式的崛起，該電商平臺想上一個拼團功能。
那麼這個功能該放到「購物車服務」裏？還是「促銷服務」裏呢？
同樣回答兩個問題：
-
購物車服務缺少了這個拼團業務，是否有至少一個流程走不通？
-
促銷服務缺少了這個拼團業務，是否有至少一個流程走不通？
首先，大家最容易想到的是，拼團一般都是直接下單，不經過購物車，自然不用放到購物車服務，放到促銷服務纔是合適的。
這個理解完全合理。但是我們可以再想一下，拼團就必須要放到促銷服務裏嗎？
拼團其實也就是一口價，也不用經過促銷的價格計算。
如此看來，拼團對促銷來說也不是“剛需”。
這個時候將拼團服務獨立出來纔是更好的選擇。因爲在這個例子裏，缺少拼團業務，對兩個服務都不會產生流程上的阻礙。
反而獨立出來後，後續對拼團業務的調整，會更容易進行。不用對購物車服務、促銷服務產生任何影響。
至此，我相信你對如何判斷一個業務的項目歸屬已經有感覺了。如果你想貫徹「高內聚低耦合」作爲系統的設計方針，不妨學習一下「領域驅動設計」。
這是由Eric Evans提出的概念，將建模作爲、劃分系統邊界等等作爲最高優先級的開發模式。
我相信，隨着未來的業務越來越複雜，基於業務作爲出發點考慮的軟件設計理念會越來越凸顯價值。
因爲技術只是實現業務的介質之一，況且新技術的產生速度正在越來越快。
那麼，與其用最好新技術，不如替業務選擇最適合的技術。
好了，我們總結一下。
這次Z哥先幫你分析了一下產生「業務歸屬」分歧背後的原因。
然後，再分享了一個正確思考這個問題的建議，還舉了兩個例子。
以後再遇到拿捏不準業務該歸屬到哪個項目的話。只要記住一句話：哪邊缺了這個業務，會有至少一個流程走不通。如果都能通，那麼這個新業務就適合“獨立門戶”。
在程序員們的日常工作中，容易發生分歧的問題還有很多，不過，其實大部分問題都有一個通解——全局的業務思維。
推薦閱讀：
作者：Zachary
出處：https://www.cnblogs.com/Zachary-Fan/p/businessattribution.html
如果你喜歡這篇文章，可以點一下右下角的「推薦」。
這樣可以給我一點反饋。: )
謝謝你的舉手之勞。
既然看到這了，送我一個「贊同」吧，支持我的創作。
想更進一步和我一起玩耍，歡迎「搜索微信公號：跨界架構師」或者在「右側掃描」。
內容包括：架構設計丨分佈式系統丨產品丨運營丨個人深度思考。