一個引起程序員們幹架的問題

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

每週五11：45 按時送達到公衆號。

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

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

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

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

可是對於輪廓模糊的業務，你們做出的決定就不必定相同了。

這個時候起決定性做用的並非各自的工做經驗，而是你的「業務思惟」是否具備全局性，以及對全局業務的瞭解程度如何。

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

看看如下的場景是否是平時有見到過？

• 嗨，小明，我這裏有個bug須要你和我一塊兒調試下。

• 當初若是這個業務在這裏就行了，如今已經積重難返了，只能推倒重作了。

• 我以爲這個問題多是這裏致使的，也有多是那裏致使的。

因此，一個業務歸屬於哪一個項目，看似是一個很簡單的選擇題。可是每一個人心中的默認選擇是不一樣的，好比如下兩種大相徑庭的傾向。

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

• 只能我這裏解決的就我這裏解決，其它的所有對方來

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

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

哪怕你們都選擇「爲他人着想「的第一點，只是避免了相互扯皮，但仍是沒法避免後續業務邊界混亂付出的額外成本。

因此，咱們仍是須要從中提煉出本質的東西做爲決策的準則。

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

由於「業務歸屬」和「高內聚低耦合」同樣，都在「劃線」，明確邊界。

可是咱們不少時候其實並不知道「線」應該具體畫在什麼位置，只是知道一個大概方位而已。

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

所以它是在分工協做下所產生的一個反作用。

可是，只要咱們繼續保持分工協做來開發一個分佈式系統，這個問題就是繞不開的一道坎。

在工做中，因爲邊界不清容易產生業務歸屬分歧的場景主要是如下兩點。

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

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

這裏先停頓一分鐘，想想，若是是你的話，該如何來做出選擇？

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

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

一個電商網站如今要上線一個會員卡的功能，相似阿里的88會員這種。

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

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

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

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

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

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

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

另外你會發現，若是促銷想實現打8折的效果，能夠徹底不須要有會員卡的存在也能作到。

因此，這個會員卡本質更像是會員屬性的一個擴展，是跟着某個具體的會員走的。

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

因此，對促銷服務來講，會員卡業務並非必不可少的。相對來講，會員服務與它的關係更緊密。

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

再來看第二個例子。

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

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

一樣回答兩個問題：

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

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

首先，你們最容易想到的是，拼團通常都是直接下單，不通過購物車，天然不用放到購物車服務，放到促銷服務纔是合適的。

這個理解徹底合理。可是咱們能夠再想一下，拼團就必需要放到促銷服務裏嗎？

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

如此看來，拼團對促銷來講也不是「剛需」。

這個時候將拼團服務獨立出來纔是更好的選擇。由於在這個例子裏，缺乏拼團業務，對兩個服務都不會產生流程上的阻礙。

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

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

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

我相信，隨着將來的業務愈來愈複雜，基於業務做爲出發點考慮的軟件設計理念會愈來愈凸顯價值。

由於技術只是實現業務的介質之一，何況新技術的產生速度正在愈來愈快。

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

好了，咱們總結一下。

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

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

之後再遇到拿捏不許業務該歸屬到哪一個項目的話。只要記住一句話：哪邊缺了這個業務，會有至少一個流程走不通。若是都能通，那麼這個新業務就適合「獨立門戶」。

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

推薦閱讀：

• 分佈式系統關注點——緩存背後的「毀滅種子」

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

做者：Zachary

出處：www.cnblogs.com/Zachary-Fan…

若是你喜歡這篇文章，能夠點一下左側的「大拇指」哦～。

這樣能夠給我一點反饋。: )

謝謝你的舉手之勞。

▶關於做者：張帆（Zachary，我的微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。歡迎掃描下方的二維碼~。

按期發表原創內容：架構設計丨分佈式系統丨產品丨運營丨一些思考。

若是你是初級程序員，想提高但不知道如何下手。又或者作程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注個人公衆號「跨界架構師」，回覆「技術」，送你一份我長期收集和整理的思惟導圖。

若是你是運營，面對不斷變化的市場一籌莫展。又或者想了解主流的運營策略，以豐富本身的「倉庫」。歡迎關注個人公衆號「跨界架構師」，回覆「運營」，送你一份我長期收集和整理的思惟導圖。