編輯導語：聊起系統架構時，架構師們總是喜歡提及“高内聚”和“低耦合”，這在系統設計中是十分重要的概念，也是産品經理需要進行學習和思考以推動業務更好開展的必備技能點。作者用生動的故事作為案例，分享了他對于高内聚和低耦合的理解，一起來看。

　　在和架構師們讨論系統設計時，總是能處處聽到“高内聚”和“低耦合”的聲音，仿佛這就是技術和産品之間的一道牆，初級和高級之間的一條溝。但如果了解了它們的原理，也就不那麼神奇了，要知道，這兩個詞并不是研發專用。作為産品經理，我們對這兩個詞的理解甚至可以比架構師們更寬廣，拽起概念來可以比他們更酷。

　　本文木筆用一個故事開始，再用一個故事結束，和你聊聊我眼裡的高内聚和低耦合，往下看！

　　聊起系統架構時，架構師們總是喜歡把“高内聚”和“低耦合”挂在嘴邊，一副拽拽不可一世的姿态，讓不懂的人聽的一愣一愣的，仿佛這就是技術和産品之間的一道牆，初級和高級之間的一條溝。那到底什麼是高内聚和低耦合，對系統設計又有什麼影響？其實，了解它們的原理以後，也就不過如此。

　　今天，木筆從一個美好的北漂故事說起，聊聊我自己對這兩個詞兒的理解，相信你看完本文以後，也能和這些架構師互拽一下了，而且，産品經理眼中的高内聚和低耦合不應該局限在系統設計本身，還應該向更源頭的業務方向思考，從業務層面做内聚和解耦。

　　在和架構師互拽時，我就一個要求，要拽得酷一點，氣勢上一定不能輸，即便臉被打腫，也要保持迷人的微笑和傲人的姿态，不要給咱産品經理丢臉。

　　一、從北京愛情故事說起 故事是這樣開始的：

　　老陳、老張、老李三人是大學同學，大學畢業後相約一起到北京闖蕩，由于初入社會工資比較低，為了省房租，3個人便一起合租，在一個房間裡擺了兩張上下鋪，延續了大學宿舍的生活方式，每天下班後就一起喝酒、吹牛、打遊戲，周末時間充裕就一起唱歌打球吃火鍋，北漂雖然窮苦，但日子過的好不快活。

　　這樣快意江湖的日子持續了三年，三條單身狗各自交了女朋友，偶爾某一位的女朋友過來，其它兩位就要出去避一避風頭，很不方便，于是三人一合計，租了一個大的三居室，每個人一間，這樣既能解決女朋友過來小聚的問題，三人也能繼續一起逍遙。随着住宿條件的提升，以及小情侶們感情的升溫，為了克服相思之苦，也為了最大化節省國家資源，小情侶們想方設法克服重重阻礙同居到一起了，這樣原本3個人的房子裡住起了6個人。

　　自從3個人變成3家6口人以後，原本的快活日子開始慢慢起了微妙變化，起因在于房間的隔音效果不怎麼好，而火爆脾氣的老陳和女朋友總是吵架，而且經常鬧到大半夜，嚴重影響了隔壁的老李和老張，時間一長，兩家小媳婦兒就有意見了。加上三家也經常因為廚房和衛生間的使用發生沖突，小媳婦兒們之間的事情，處理起來再也不像以前3個大老爺們那麼簡單粗暴了，一旦處理不好，後果大家都懂……

　　半年以後，為了避免女友之間的矛盾進一步加大變得不可開交，老張、老李和老陳最終決定不再續租，三人各自帶女友出去租單間了，周末有空才到一起聚會。這樣一來，雖然老陳還是經常和女友吵架，依舊睡的晚，但三家合租時候遇到的所有的問題都就此化解了，沒有了沖突，三位女友見面以後反倒比之前合租時更加親切了……

　　故事講完了，如果你也曾有過幾位類似的室友和經曆，那麼你無疑是幸運的，因為那些恰同學少年一起合租的日子就像昙花，美妙而短暫，那些一起為夢想窮開心的日子終将成為人生旅途中最珍貴的一段回憶，而它也終将随時光一去不返。

　　不過本文的重點不是為緬懷青春，而是想從故事中提煉出我們需要的主幹：高内聚和低耦合。我們從資源分配角度來分析為何最早3個人合租的時候關系很好，變3家合租以後，就會出現矛盾，而後來各自分開住以後，關系又變好了呢？先思考3秒鐘….

　　二、什麼是高内聚和低耦合 把故事暫放一邊，我們先理解一下什麼是内聚和耦合。

　　所謂内聚，指某一個事物内部各要素之間的緊密聯系程度。如果相同的要素越集中，說明内聚越高，反之則越低。比如人身體裡的五髒六腑，彼此之間從出生就相互協作，如果換成其他人的器官，就會出現排斥現象，這就是高内聚。

　　所謂耦合，指不同事物之間的依賴性。如果彼此的依賴性越強，說明耦合性越高，反之則越低。還拿人體舉例，心髒負責供血，肺負責呼吸，肝髒負責代謝，彼此之間分工明确，各司其職，即便某一部位生病了，隻需要針對性治療，不影響其它部位，這就是低耦合。

　　了解完概念以後，我們再回來分析一下故事的結局：為何最早3個人合租的時候關系很好，變3家合租以後，就會出現矛盾，而後來各自分開住以後，關系又變好了呢？

　　答案揭曉：最初3個人合租時，省錢最重要，人少感情鐵，事情簡單，所以不會有大的矛盾。而變成3家以後就成了3個不同的家庭，每個家庭的計劃和訴求不一樣，省錢已經不是第一訴求了，同在一個屋檐下，老陳和女朋友的家事免不了會影響到老張和老李兩家，加上大家平時共用廚房、衛生間等公共資源，隻要一家在使用，其它兩家就會受到影響，而老陳、老張、老李的女朋友之間并不像他們三人之前一樣生活單一且有着深厚的感情基礎，久而久之，自然就出現矛盾了。

　　最後随着三家分開以後，自己過自己的生活，再也不會影響到其它兩家，矛盾自然就沒有了，随着偶爾的聯絡聚會，還會增進彼此的感情。

　　老陳、老張和老王的合租

　　這就是高内聚和低耦合的原理。最初三人合租時，人少、有感情基礎，省錢第一，不存在内聚和耦合問題；三家6人合租時，彼此之間依賴太多，任何一家的舉動都會影響到其它兩家，耦合性太高，所以容易出問題；分開以後，每家獨自負責自己的生活，不再依賴别人，内聚性變高了，同時隻有周末才會相互聯絡，耦合性降低了，所以關系更親近了。

　　看看，是不是和我們的系統設計一樣一樣的？當系統很小時，為節約資源，大家在一起共用一套資源，這樣效率最高，而随着系統和團隊的複雜度逐漸提升，彼此之間的依賴越來越高，就會經常出現資源問題和發展瓶頸，到最後，為了解決耦合性高的問題，隻能對系統和團隊進行拆分，各司其職，最終演變成了标準的高内聚和低耦合模型。

　　三、如何實現高内聚和低耦合 從定義上，我們應該清楚了高内聚和低耦合其實說的是兩件事，一件事對内（高内聚），一件事對外（低耦合）。站在産品的視角，高内聚和低耦合不應該隻局限于系統設計層面，那樣就顯得比較狹隘了，正确的解讀應該立為業務和系統兩個層面。

　　高内聚與低耦合示例

　　1. 業務層面

　　無論是業務部門的責任分工、流程的規劃和設計，還是作業現場的管理，都需要遵循高内聚和低耦合，我們應該盡量将相同的職能、流程和運營工作盡量集中式管理，而不同職能、流程和運營之間責任和邊界清晰，溝通協作順暢且不相互影響，具體體現為：

　　（1）各部門和崗位分工明确，各司其職。例如采購、倉儲和配送，雖然交集很多，但在定人定崗時，就應該是不同的崗位角色，即便有的公司很小，可以一人身兼數職，但也要清楚，隻是一個人做了多個崗位的事，而不是多個職能融合成了一個崗位。

　　（2）各項流程清晰，職責單一。在設計業務流程時，應該考慮單一職能原則，每套流程解決一個核心業務場景，雖然很多時候人和功能可以複用，但在流程和規則層面還是要分開設計，不要混在一起。例如銷售出庫和退供應商出庫，雖然都是出庫，系統功能和操作人都可以複用，但出庫的對象不同，應該視為兩種業務流程。

　　（3）現場管理規章明确，流向清晰。在倉儲中心、物流中心的現場管理時，需要按照不同崗位、不同商品和不同業務形态規劃庫區、動線流向，制訂規章制度，例如收發貨區域管理、整件和散件區域管理、大件區和中小件區域管理等，讓每個流程對應不同的規則，每個區域負責不同的存儲形态，每個崗位操作不同的業務單據，彼此之間能無縫銜接卻又不相互幹擾。

　　2. 系統層面

　　在做系統設計時，需要保證相同的系統和功能模塊盡量内聚，系統和功能模塊之間盡量解耦，體現為：

　　系統和模塊職能單一，邊界清晰。在規劃系統時，應該做到每個系統，以及每個系統下的每個功能模塊都有很清晰的職責，核心職責隻有一個，并且和其它模塊之間有比較清晰的邊界，避免模棱兩可。例如庫存模塊負責處理所有庫存相關事宜，入庫模塊負責處理入庫業務流程，二者的邊界在入庫上架時對庫存的處理，由入庫模塊觸發，庫存模塊做執行。數據和邏輯統一，唯一主責方。每個數據和邏輯的操作應該隻有一個主責方，當其它模塊需要操作此數據時，應該由此模塊授權并通過接口服務的方式互通，如此可以最大化的保證數據和功能的完整和安全。例如入庫和出庫都需要操作庫存，但庫存的邏輯統一由庫存模塊來處理，出入庫操作庫存需要通過庫存模塊提供的接口來交互，千萬不要把庫存的處理直接交給入庫和出庫模塊來各自處理。與盡量少的系統交互，降低系統之間的複雜性。參考軟件設計原則裡的迪米特法則：隻與你的直接朋友交談，不跟“陌生人”說話（Talk only to your immediate friends and not to strangers），盡量避免多個系統之間相互交互，形成了笛卡爾積和網狀結構。比如上方有3個ERP，都需要要與下方的3個WMS系統做交互，這個時候就應該考慮通過一個中間的系統來對上承接3個ERP，對下對接3個WMS系統，不要讓每個ERP分别與每個WMS形成笛卡爾積。 當然，高内聚和低耦合的設計雖然看起來更合理，但在實現時還是要因時制宜，因為高内聚和低耦合的實現一定會帶來人力成本和系統實現成本的增加，就像北漂故事中一樣，老陳老張和老李三家分開以後，确實實現了高内聚和低耦合，但每個人都需要自己租單間，還需要置配生活用品和廚房用具，總成本一定比合租時要高，比起最初三人合租一間房時就更高得多了。

　　在設計流程和系統時，我們應該根據實際情況來定奪，沒必要照本宣科過度設計，在此，木筆提供幾個思考建議：

　　系統設計來源于業務，做系統的内聚和耦合之前，先從業務層面進行梳理，讓業務先做好高内聚和低耦合，很多時候問題不是出在系統上，而是業務側沒有做好内聚和解耦。當業務發展初期，流程和系統相對簡單且未來尚不清晰時，需要快速試錯，可以不用太考慮内聚和耦合（适當兼顧就行），先以成本最低的方式支持業務，等業務慢慢清晰以後再繼續調整也不遲，千萬不要過度設計，用10萬單的規模架構太承接1000單的業務，實打實的浪費。如果業務相對穩定，長期不變，适當耦合會更合理，比如商品的基本屬性、訂單的關鍵信息、地址庫信息等，沒必要為了低耦合，每次都做接口交互，這樣比較浪費性能。當業務體量和團隊規模都很小時，适合合租模式，一套系統中考慮按模塊做高内聚和低耦合最合理；而當業務規模較大時，适合分開自住模式，分成多套系統，各系統内部高内聚，系統間低耦合更合理。四、小Q的故事分享 最後，我們分享一個小Q的故事來加強對高内聚和低耦合的理解。

　　小Q最近有點煩，事情經過是這樣的：

　　上個月自己剛入職了Z公司負責倉儲系統的産品工作，剛入職就遇到前任産品經理離職，兩人在交接的過程中才知道這套WMS系統是前不久才開發上線的，但因為系統問題較多，導緻系統庫存記錄的嚴重不準，才1個月就産生了1000多萬的賬實差異，而且差異越來越大，已經嚴重影響了公司的銷售，每天被銷售部門、倉儲部門和财務部門多方逼着解決，前任實在頂不住壓力了，所以才提了離職，後來公司才招了小Q入職……原來如此。如果要評出職場上最坑的事，這種入職即背鍋一定能排進前三。

　　小Q剛開始還沒意識到問題的嚴重性，直到被倉儲業務方在郵件裡将盤點差異直接抄送CEO，并點名要求技術部門為庫存差異負責并責令修複系統問題，限期1個月。為了不惹火上身，小Q當即提出離職，被領導好說歹說挽留下來，并為其增加了績效獎金，因為目前最專業的人隻有小Q了，隻能死馬當作活馬醫。重賞之下，兩人商定以1個月為限，領導答應給小Q協調足夠的資源來解決此問題。

　　小Q拉上研發經理和測試經理成立了專項組，先從業務的差異數據開始着手，從差異最大的業務開始排查，不多久便根據自己的經驗發現了問題的根本：新的WMS系統研發團隊都沒有庫存處理相關經驗，在做庫存處理設計時，都是在各個業務模塊中自行處理，各自模塊負責自己模塊的庫存加減，直接操作庫存表，這樣看起來各業務之間互不幹預，似乎很解耦很合理。

　　但大家都忽略了一個現實：業務是并行的，在入庫的時還可能在做出庫、盤點等業務，雖然每個業務都是各自開展，但一旦針對某一個SKU同時操作多個業務時，庫存的處理就會相互牽制，往往上一個業務還沒處理完庫存，下個業務又對庫存操作了變更，這就産生了庫存的操作錯亂，所以産生了庫存差異。看起來解耦的設計，實際上是各種業務和庫存的處理高度耦合導緻的問題。

　　Z公司的庫存處理現狀

　　這麼嚴重的問題，測試時為什麼沒有發現呢？因為測試時樣本太少，根本沒有測到這種業務并發的情況。

　　找到問題根本以後，小Q稍微松了一口氣，根據經驗很快出具了一個庫存解決方案：将庫存的處理單獨抽出來做成公共服務，整個系統隻能基于此服務操作庫存表，保證前一個業務加減完成後再執行下一個業務操作，并記錄詳細的庫存變更流水日志。

　　對外則提供公共的庫存的加減公共服務，這樣各倉儲業務環節隻需要處理業務邏輯，在需要變更庫存時再調用庫存服務完成對庫存的處理，不用再關注庫存的底層邏輯了，如此才是真正的各業務内部高内聚（每個業務隻關注處理自己的業務邏輯），業務和庫存之間低耦合（通過唯一接口交互）。

　　小Q改造後的庫存處理方案

　　方案出具以後，技術團隊用1周時間完成了庫存的重構，并按照差異大小排序，将各業務逐一往新的庫存服務中遷移，雖然業務仍然在天天緊逼，但看着庫存差異在一天天縮小，小Q知道自己的新方案湊效了，如此下去，不到1個月，庫存問題就能得到徹底根治了…

　　案例也分享完了，以上就是我個人對高内聚和低耦合的一些見解了，最後想說的是，高内聚和低耦合的設計隻是最終的實現形式，而它們更多的價值體現在我們梳理過程中的一種結構化思維方式，這是一種放諸四海都有用的方法。在做内聚時，我們要學會歸納、抽象，讓相同的業務和功能盡量緊湊，在做耦合時，我們要學會将聯系比較密切的流程、邏輯和功能拆分、剝離再重組和内聚，切忌藕斷絲連。

　　我的文章分享完了，觀點如上，夠不夠出去拽一下，就看你的了。

　　#專欄作者#

　　木筆，産品一俗生，深耕于供應鍊領域，供應鍊産品筆記

　　本文原創發布于人人都是産品經理。未經許可，禁止轉載

　　題圖來自Unsplash，基于CC0協議

　　,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!