B端教育產品如何降低模塊之間的耦合，做出低耦合設計？

作為一名面向教育機構B端產品經理，往往需要設計的是整個教育行業的方方面面的流程。當然，通常情況下是按照模塊的不同進行設計，比如學生相關模塊、教師相關模塊、考試相關模塊等。

這些模塊、功能、流程或複雜或簡單，簡單的流程就不必説了，當設計複雜功能模塊時，模塊之間很強的邏輯聯繫，較高的數據依賴性，在流程梳理和整個設計過程中，是令人十分頭疼的事兒。

那麼怎樣在一開始通過梳理和分析，達到簡單優雅的設計，這樣的問題就擺在我們面前。

一、降低模塊之間耦合度必要性

複雜的功能模塊除了本身的流程複雜外，最重要的是它是建立在別的較完善的模塊流程的基礎上，同樣模塊流程本身的輸出又是另外的一個模塊完善的前提。

這樣交織的模塊關係，使整個系統錯綜複雜，具有較強的耦合度，在做功能擴展的時候，牽一髮而動全身。降低模塊之間的耦合度是十分重要的一件事兒，其優勢如下：

1. 模塊之間的耦合程度越低，相互影響就越小，發生異常後產生連鎖反應的概率就越低；
2. 在修改一個模塊時，低耦合的系統可以把修改範圍儘量控制在最小的範圍內；
3. 對一個模塊進行維護時，其他模塊的內部程序的正常運行不會受到較大的影響。

那麼，如何做到降低系統模塊之間的耦合度？

筆者認為可以從以下入手:

二、降低耦合度的方法

在軟件工程中，降低耦合度，又稱“解耦”，模塊間有依賴關係必然存在耦合，理論上絕對的零耦合是做不到的，但是可以通過一定的方法將耦合度降至最低。B端系統在設計時解耦的方法要從邏輯，研發兩方面考慮。

作為產品經理將產品線的發展規律，管理差異化，系統平台支撐方面進行邏輯梳理。當然技術方面也要進行模塊化微服務，做到客户、合同、付款、服務、服務評價五個維度的數據閉環。

模塊間數據傳輸，模塊內部邏輯判斷。開發人員應該儘量使用數據耦合，較少使用控制耦合，限制公共耦合的使用範圍，同時堅決避免使用內容耦合。

言歸正傳，產品經理如何在一開始設計的時候降低各應用模塊之間的耦合度，這是本文討論的重點。一開始就做到最優解耦不太容易，這是一個從混沌走向清晰的漸進明細過程，我個人認為可以從以下幾方面來入手：

1. 明晰並理解需求，瞭解現有的系統

1）業務流程圖

B端以業務流為主，業務流程圖是首要需要明確的，而且需要足夠概括，抽象，這樣業務流程可以按不同角色來進行劃分，每個角色在每個環節在什麼情況下都需要幹什麼、有什麼權限、涉及到什麼模塊和數據等，由此也可把角色權限進行定義了。

2）流程狀態梳理

就是不同的業務流，有哪幾種狀態，每種狀態之間切換的條件是什麼，到底有多少條通路，需要模擬各種情況的數據走一遍。

3）系統架構圖

整體的系統架構是由不同的流程不同狀態構成的公共合集，在設計系統架構圖時，需要明確涉及到的前台業務、底層系統、各個系統模塊，明確業務範圍，若有改動涉及到其他系統，需要梳理並抽取出共性。

通過這幾個步驟，由業務流轉化為了抽象的系統架構圖，當然這是產品自己梳理的1.0版，還需要對整個系統影響的各相關方進行訪談。

2. 對上下游系統相關方進行訪談，根據訪談結果綜合分析後更新相關流程圖、架構圖

• 現有系統的研發人員：系統能實現什麼不能實現什麼，肯定看了代碼就知道了，梳理相關邏輯的時候可以分專題與研發人員進行討論，一定要控制好不要跑題。
• 熟悉相關業務的產品或項目經理：熟悉歷史經驗教訓及組織過程資產往往能夠降低後續的項目風險，有哪些是設計如此、哪些是遺留問題，相關的產品同事多少會知道一些。
• 運營、最終用户及測試人員：運營人員與最終用户是使用系統最多的相關方，運營與測試人員往往能提出很多絕妙的優化建議，有利於產品同事進行梳理。

3. 配合營銷指標及技術指標進行優化，雖然這是後期的事兒

很多時候系統的業務量或用户量達到一定程度時會遇到瓶頸，市場同事在銷售時也肯定會有相關的數據指標，產品的設計、模塊的解耦往往也可以與這些需求一併考慮：

• 技術優化：業務延遲的忍耐程度、流程的長度、數據的歸檔週期等；
• 營銷指標：線索和商機的獲取週期、用户的使用體驗等。

三、具體實現步驟

在具體操作的時候，我們可以採用以下思路：

1. 梳理原子服務

梳理承載業務的系統所需要的模塊，然後將這些模塊拆分為一個個功能點，將相似的功能點合併為一個獨立的服務，提供單獨的一項能力，合併服務要保證每個服務都可以單獨對外提供服務且每個服務提供的能力不重合，這種稱之為原子服務。

這個步驟的完成的好壞取決於：

• 你對業務對理解能力，如果是從0-1可以參考其他教育行業友商競品，如果不是可以參考現有系統；
• 你對業務所處行業發展的思考，這個很大程度決定你服務的拓展性和合理性，這個可以結合行業發展史和你自己的知識認知，比較抽象；
• 邊界一定要清晰，要明晰所做功能的邊界和現實中技術的侷限性，既要天馬行空、又要明確系統邊界。

2. 找出這些服務裏面的共用項，做成最底層的配置規則，然後讓他服務來調用

舉個例子：設施設備管理及相關數據採集，經常涉及多硬件、多變成語言，那麼每個模塊的框架語言包就是一個共用項，這樣做的目的是保證各維度數據的一致性。

3. 有時候一個業務閉環其實需要多個服務一起提供服務，這時需要再加一層服務聚合，保證原子服務的獨立性

總之，一般應該採用：梳理出獨立原子服務（保證獨立不耦合）——找出公共底層配置項（保證維度數據統一）——聚合服務支持業務（保證原子服務解耦）這樣的流程。

四、總結

充分的降低各個模塊的耦合性，是複雜的教育系統必須解決的問題，系統的解耦要從邏輯，研發兩方面結構。將產品線的發展規律，管理差異化，系統平台支撐方面進行邏輯梳理。技術方面要進行模塊化微服務。

這樣對後期產品功能的擴展、系統的演進都會有很大的幫助。

本文由 @Cloudzhang 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議