這里是Z哥的個人公眾號

每周五早8點 按時送達

當然了，也會時不時加個餐～

我的第「77」篇原創敬上

在一個分布式系統的開發團隊中，有一些問題是很容易產生程序員之間矛盾的。

其中之一就是「業務歸屬」，就是當新加/修改一個業務的時候，代碼變更應該放到你負責的系統還是我負責的系統里？

一些業務輪廓很清晰的就不用說了，大家的認定都是一樣的。比如商品相關的放到商品服務，會員相關的放到會員服務。

但是對于輪廓模糊的業務，大家作出的決定就不一定相同了。

這個時候起決定性作用的并不是各自的工作經驗，而是你的「業務思維」是否具有全局性，以及對全局業務的了解程度如何。

一旦草率的作出了“不合適”的歸屬劃定，后續將會帶來大量的額外成本，協作、更高的bug率等等。

看看以下的場景是不是平時有見到過？

• 嗨，小明，我這里有個bug需要你和我一起調試下。

• 當初如果這個業務在這里就好了，現在已經積重難返了，只能推倒重做了。

• 我覺得這個問題可能是這里導致的，也有可能是那里導致的。

所以，一個業務歸屬于哪個項目，看似是一個很簡單的選擇題。但是每個人心中的默認選擇是不同的，比如以下兩種截然不同的傾向。

• 我能解決的就我解決咯，實在解決不了的再給對方

• 只能我這里解決的就我這里解決，其它的全部對方來

其實這些選擇都是因人而異的，很難形成一個放之四海而皆準的共識。

如果雙方都選擇第二點，產生沖突、爭執是必然的。

哪怕大家都選擇“為他人著想“的第一點，只是避免了相互扯皮，但還是無法避免后續業務邊界混亂付出的額外成本。

所以，我們還是需要從中提煉出本質的東西作為決策的準則。

Z哥我認為思考業務歸屬的時候，本質上還是逃不開「高內聚低耦合」范圍，一個合理的項目歸屬認定，會讓軟件系統離每個人所期望的「高內聚低耦合」更近一步。

因為「業務歸屬」和「高內聚低耦合」一樣，都在“劃線”，明確邊界。

但是我們很多時候其實并不知道“線”應該具體畫在什么位置，只是知道一個大概方位而已。

其實，如果當我們的系統只是一個單體應用的話，是不存在「業務歸屬」問題的。

因此它是在分工協作下所產生的一個副作用。

但是，只要我們繼續保持分工協作來開發一個分布式系統，這個問題就是繞不開的一道坎。

在工作中，由于邊界不清容易產生業務歸屬分歧的場景主要是以下兩點。

• 一個新業務，需要兩邊配合完成

• 一個老業務，一部分在A處理，一部分在B處理。

這里先停頓一分鐘，想一想，如果是你的話，該如何來作出選擇？

Z哥我給你的建議是，你可以這樣來考慮：哪邊缺了這個業務的話，會導致至少一個流程走不通。

來舉兩個例子幫助你理解。

一個電商網站現在要上線一個會員卡的功能，類似阿里的88會員這種。?

效果是買了這個會員卡的用戶，在該平臺購買自營商品時，享受8折優惠。

那么你來思考一下？這個業務到底是放到「會員服務」還是「促銷服務」？

參照上面的建議來思考就是回答兩個問題：

• 會員服務缺少了這個會員卡業務，是否有至少一個流程走不通？

• 促銷服務缺少了這個會員卡業務，是否有至少一個流程走不通？

很顯然，會員卡雖然有一個打折功能，但是這個打折是建立在一個身份標識上的。

那么就要思考一下，這個身份標識后續是否會在整個購物鏈路中的多個環節有露出展示或者對應的專屬業務，比如專屬客服、每月領福利等等。

另外你會發現，如果促銷想實現打8折的效果，可以完全不需要有會員卡的存在也能做到。

所以，這個會員卡本質更像是會員屬性的一個擴展，是跟著某個具體的會員走的。

假如最終不小心被歸屬到了促銷服務，則每次圍繞會員卡展開的業務都需要與促銷服務產生耦合才能完成，很明顯就背離了「高內聚低耦合」的初衷。

所以，對促銷服務來說，會員卡業務并不是必不可少的。相對來說，會員服務與它的關系更緊密。

至此，第一個例子的答案就出來了，應該放到會員服務。

再來看第二個例子。

隨著社交電商模式的崛起，該電商平臺想上一個拼團功能。

那么這個功能該放到「購物車服務」里？還是「促銷服務」里呢？

同樣回答兩個問題：

• 購物車服務缺少了這個拼團業務，是否有至少一個流程走不通？

• 促銷服務缺少了這個拼團業務，是否有至少一個流程走不通？

首先，大家最容易想到的是，拼團一般都是直接下單，不經過購物車，自然不用放到購物車服務，放到促銷服務才是合適的。

這個理解完全合理。但是我們可以再想一下，拼團就必須要放到促銷服務里嗎？

拼團其實也就是一口價，也不用經過促銷的價格計算。

如此看來，拼團對促銷來說也不是“剛需”。

這個時候將拼團服務獨立出來才是更好的選擇。因為在這個例子里，缺少拼團業務，對兩個服務都不會產生流程上的阻礙。

反而獨立出來后，后續對拼團業務的調整，會更容易進行。不用對購物車服務、促銷服務產生任何影響。

至此，我相信你對如何判斷一個業務的項目歸屬已經有感覺了。如果你想貫徹「高內聚低耦合」作為系統的設計方針，不妨學習一下「領域驅動設計」。

這是由Eric Evans提出的概念，將建模作為、劃分系統邊界等等作為最高優先級的開發模式。

我相信，隨著未來的業務越來越復雜，基于業務作為出發點考慮的軟件設計理念會越來越凸顯價值。

因為技術只是實現業務的介質之一，況且新技術的產生速度正在越來越快。

那么，與其用最好新技術，不如替業務選擇最適合的技術。

好了，我們總結一下。

這次Z哥先幫你分析了一下產生「業務歸屬」分歧背后的原因。

然后，再分享了一個正確思考這個問題的建議，還舉了兩個例子。

以后再遇到拿捏不準業務該歸屬到哪個項目的話。只要記住一句話：哪邊缺了這個業務，會有至少一個流程走不通。如果都能通，那么這個新業務就適合“獨立門戶”。

在程序員們的日常工作中，容易發生分歧的問題還有很多，不過，其實大部分問題都有一個通解——全局的業務思維。

推薦閱讀：

• 分布式系統關注點——緩存背后的“毀滅種子”

• 8個月打磨，一份送給程序員的「分布式系統」合集

原創不易，如果你覺得這篇文章還不錯，就「在看」或者「分享」一下吧。鼓勵我的創作 ：）

如果有希望我寫一下什么主題的話，歡迎在后臺給我留言哦～

總結

以上是生活随笔為你收集整理的一个引发程序员们干架的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。