如果第二次看到我的文章，歡迎「文末」掃碼訂閱我個人的公眾號（跨界架構師）喲~

每週五早8點按時送達到公眾號。 當然了，也會時不時加個餐～

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

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

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

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

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

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

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

嗨，小明，我這裡有個bug需要你和我一起除錯下。

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

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

所以，一個業務歸屬於哪個專案，看似是一個很簡單的選擇題。但是每個人心中的預設選擇是不同的，比如以下兩種截然不同的傾向。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

再來看第二個例子。

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

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

同樣回答兩個問題：

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

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

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

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

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

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

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

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

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

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

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

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

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

好了，我們總結一下。

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

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

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

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

一個引發程式設計師們幹架的問題

相關文章