B端教育產(chǎn)品如何降低模塊之間的耦合,做出低耦合設(shè)計?
編輯導(dǎo)語:B端教育產(chǎn)品的設(shè)計往往需要經(jīng)過很多流程,涉及教育行業(yè)的方方面面。當(dāng)我們設(shè)計一個較為復(fù)雜的功能模塊時,應(yīng)該如何降低模塊之間的耦合,從而做出低耦合的設(shè)計呢?作者結(jié)合經(jīng)驗進行了梳理和分析,總結(jié)出了如何才能達到簡單優(yōu)雅的設(shè)計的方法論。
作為一名面向教育機構(gòu)B端產(chǎn)品經(jīng)理,往往需要設(shè)計的是整個教育行業(yè)的方方面面的流程。當(dāng)然,通常情況下是按照模塊的不同進行設(shè)計,比如學(xué)生相關(guān)模塊、教師相關(guān)模塊、考試相關(guān)模塊等。
這些模塊、功能、流程或復(fù)雜或簡單,簡單的流程就不必說了,當(dāng)設(shè)計復(fù)雜功能模塊時,模塊之間很強的邏輯聯(lián)系,較高的數(shù)據(jù)依賴性,在流程梳理和整個設(shè)計過程中,是令人十分頭疼的事兒。
那么怎樣在一開始通過梳理和分析,達到簡單優(yōu)雅的設(shè)計,這樣的問題就擺在我們面前。
一、降低模塊之間耦合度必要性
復(fù)雜的功能模塊除了本身的流程復(fù)雜外,最重要的是它是建立在別的較完善的模塊流程的基礎(chǔ)上,同樣模塊流程本身的輸出又是另外的一個模塊完善的前提。
這樣交織的模塊關(guān)系,使整個系統(tǒng)錯綜復(fù)雜,具有較強的耦合度,在做功能擴展的時候,牽一發(fā)而動全身。降低模塊之間的耦合度是十分重要的一件事兒,其優(yōu)勢如下:
- 模塊之間的耦合程度越低,相互影響就越小,發(fā)生異常后產(chǎn)生連鎖反應(yīng)的概率就越低;
- 在修改一個模塊時,低耦合的系統(tǒng)可以把修改范圍盡量控制在最小的范圍內(nèi);
- 對一個模塊進行維護時,其他模塊的內(nèi)部程序的正常運行不會受到較大的影響。
那么,如何做到降低系統(tǒng)模塊之間的耦合度?
筆者認為可以從以下入手:
二、降低耦合度的方法
在軟件工程中,降低耦合度,又稱“解耦”,模塊間有依賴關(guān)系必然存在耦合,理論上絕對的零耦合是做不到的,但是可以通過一定的方法將耦合度降至最低。B端系統(tǒng)在設(shè)計時解耦的方法要從邏輯,研發(fā)兩方面考慮。
作為產(chǎn)品經(jīng)理將產(chǎn)品線的發(fā)展規(guī)律,管理差異化,系統(tǒng)平臺支撐方面進行邏輯梳理。當(dāng)然技術(shù)方面也要進行模塊化微服務(wù),做到客戶、合同、付款、服務(wù)、服務(wù)評價五個維度的數(shù)據(jù)閉環(huán)。
模塊間數(shù)據(jù)傳輸,模塊內(nèi)部邏輯判斷。開發(fā)人員應(yīng)該盡量使用數(shù)據(jù)耦合,較少使用控制耦合,限制公共耦合的使用范圍,同時堅決避免使用內(nèi)容耦合。
言歸正傳,產(chǎn)品經(jīng)理如何在一開始設(shè)計的時候降低各應(yīng)用模塊之間的耦合度,這是本文討論的重點。一開始就做到最優(yōu)解耦不太容易,這是一個從混沌走向清晰的漸進明細過程,我個人認為可以從以下幾方面來入手:
1. 明晰并理解需求,了解現(xiàn)有的系統(tǒng)
1)業(yè)務(wù)流程圖
B端以業(yè)務(wù)流為主,業(yè)務(wù)流程圖是首要需要明確的,而且需要足夠概括,抽象,這樣業(yè)務(wù)流程可以按不同角色來進行劃分,每個角色在每個環(huán)節(jié)在什么情況下都需要干什么、有什么權(quán)限、涉及到什么模塊和數(shù)據(jù)等,由此也可把角色權(quán)限進行定義了。
2)流程狀態(tài)梳理
就是不同的業(yè)務(wù)流,有哪幾種狀態(tài),每種狀態(tài)之間切換的條件是什么,到底有多少條通路,需要模擬各種情況的數(shù)據(jù)走一遍。
3)系統(tǒng)架構(gòu)圖
整體的系統(tǒng)架構(gòu)是由不同的流程不同狀態(tài)構(gòu)成的公共合集,在設(shè)計系統(tǒng)架構(gòu)圖時,需要明確涉及到的前臺業(yè)務(wù)、底層系統(tǒng)、各個系統(tǒng)模塊,明確業(yè)務(wù)范圍,若有改動涉及到其他系統(tǒng),需要梳理并抽取出共性。
通過這幾個步驟,由業(yè)務(wù)流轉(zhuǎn)化為了抽象的系統(tǒng)架構(gòu)圖,當(dāng)然這是產(chǎn)品自己梳理的1.0版,還需要對整個系統(tǒng)影響的各相關(guān)方進行訪談。
2. 對上下游系統(tǒng)相關(guān)方進行訪談,根據(jù)訪談結(jié)果綜合分析后更新相關(guān)流程圖、架構(gòu)圖
- 現(xiàn)有系統(tǒng)的研發(fā)人員:系統(tǒng)能實現(xiàn)什么不能實現(xiàn)什么,肯定看了代碼就知道了,梳理相關(guān)邏輯的時候可以分專題與研發(fā)人員進行討論,一定要控制好不要跑題。
- 熟悉相關(guān)業(yè)務(wù)的產(chǎn)品或項目經(jīng)理:熟悉歷史經(jīng)驗教訓(xùn)及組織過程資產(chǎn)往往能夠降低后續(xù)的項目風(fēng)險,有哪些是設(shè)計如此、哪些是遺留問題,相關(guān)的產(chǎn)品同事多少會知道一些。
- 運營、最終用戶及測試人員:運營人員與最終用戶是使用系統(tǒng)最多的相關(guān)方,運營與測試人員往往能提出很多絕妙的優(yōu)化建議,有利于產(chǎn)品同事進行梳理。
3. 配合營銷指標(biāo)及技術(shù)指標(biāo)進行優(yōu)化,雖然這是后期的事兒
很多時候系統(tǒng)的業(yè)務(wù)量或用戶量達到一定程度時會遇到瓶頸,市場同事在銷售時也肯定會有相關(guān)的數(shù)據(jù)指標(biāo),產(chǎn)品的設(shè)計、模塊的解耦往往也可以與這些需求一并考慮:
- 技術(shù)優(yōu)化:業(yè)務(wù)延遲的忍耐程度、流程的長度、數(shù)據(jù)的歸檔周期等;
- 營銷指標(biāo):線索和商機的獲取周期、用戶的使用體驗等。
三、具體實現(xiàn)步驟
在具體操作的時候,我們可以采用以下思路:
1. 梳理原子服務(wù)
梳理承載業(yè)務(wù)的系統(tǒng)所需要的模塊,然后將這些模塊拆分為一個個功能點,將相似的功能點合并為一個獨立的服務(wù),提供單獨的一項能力,合并服務(wù)要保證每個服務(wù)都可以單獨對外提供服務(wù)且每個服務(wù)提供的能力不重合,這種稱之為原子服務(wù)。
這個步驟的完成的好壞取決于:
- 你對業(yè)務(wù)對理解能力,如果是從0-1可以參考其他教育行業(yè)友商競品,如果不是可以參考現(xiàn)有系統(tǒng);
- 你對業(yè)務(wù)所處行業(yè)發(fā)展的思考,這個很大程度決定你服務(wù)的拓展性和合理性,這個可以結(jié)合行業(yè)發(fā)展史和你自己的知識認知,比較抽象;
- 邊界一定要清晰,要明晰所做功能的邊界和現(xiàn)實中技術(shù)的局限性,既要天馬行空、又要明確系統(tǒng)邊界。
2. 找出這些服務(wù)里面的共用項,做成最底層的配置規(guī)則,然后讓他服務(wù)來調(diào)用
舉個例子:設(shè)施設(shè)備管理及相關(guān)數(shù)據(jù)采集,經(jīng)常涉及多硬件、多變成語言,那么每個模塊的框架語言包就是一個共用項,這樣做的目的是保證各維度數(shù)據(jù)的一致性。
3. 有時候一個業(yè)務(wù)閉環(huán)其實需要多個服務(wù)一起提供服務(wù),這時需要再加一層服務(wù)聚合,保證原子服務(wù)的獨立性
總之,一般應(yīng)該采用:梳理出獨立原子服務(wù)(保證獨立不耦合)——找出公共底層配置項(保證維度數(shù)據(jù)統(tǒng)一)——聚合服務(wù)支持業(yè)務(wù)(保證原子服務(wù)解耦)這樣的流程。
四、總結(jié)
充分的降低各個模塊的耦合性,是復(fù)雜的教育系統(tǒng)必須解決的問題,系統(tǒng)的解耦要從邏輯,研發(fā)兩方面結(jié)構(gòu)。將產(chǎn)品線的發(fā)展規(guī)律,管理差異化,系統(tǒng)平臺支撐方面進行邏輯梳理。技術(shù)方面要進行模塊化微服務(wù)。
這樣對后期產(chǎn)品功能的擴展、系統(tǒng)的演進都會有很大的幫助。
本文由 @Cloudzhang 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自?Unsplash,基于 CC0 協(xié)議
親身體會,“流程狀態(tài)梳理” 這個非常非常重要,如果能展開講一下就美了~
具體想了解哪些?可以關(guān)注公眾號留言。共同探討!
概念很好,不過缺少一些具體的示意圖。
學(xué)習(xí)收藏了,今天就當(dāng)一回課代表吧。搭建私域流量運營,當(dāng)然必須要有工具。給大家推薦一款由【人人都是產(chǎn)品經(jīng)理】【起點課堂】旗下獨立研發(fā)的私域流量運營工具——糧倉·企微管家。糧倉·企微管家是一款基于企業(yè)微信的一款營銷型SCRM系統(tǒng)。集裂變獲客、留存促活、銷售變現(xiàn)、客戶管理于一體的私域增長閉環(huán)系統(tǒng)。覆蓋企業(yè)客戶運營的生命周期,助力企業(yè)私域流量運營,提升售前/售后服務(wù)能力。還可以免費開始使用哦~ http://996.pm/M0A06
沒有實例,很難讓我有入木三分的理解。本來可以100分,結(jié)果就差那么一點。
哈哈 篇幅有限
1、建議不要盲目解耦,B端的產(chǎn)品各個模塊本身就可能互相管理,將各個模塊拆分太開,對于跨模塊的數(shù)據(jù)支持是非常差的,這回導(dǎo)致業(yè)務(wù)支持能力會收到阻礙,除非可以保證各個領(lǐng)域的模塊自己就可以完成閉環(huán),對其它模塊沒有影響;
2、對于大型復(fù)雜的系統(tǒng),建議了解下DDD(領(lǐng)域驅(qū)動設(shè)計)
多謝交流;有些問題要說明一下:
1.b端產(chǎn)品重要的一方面是定制化,同一個領(lǐng)域的客戶上層應(yīng)用需求會有很大的差別,各模塊完成一個閉環(huán),降低相互之間的耦合度,對迅速適應(yīng)定制化需求有很大幫助。
2.DDD需要在領(lǐng)域建?;ㄙM很多的時間和精力,付出和收益不一定成正比,現(xiàn)狀是大廠仍在有選擇的使用,具體落地的不多。
哇偶,大佬,你們真是666666!
對于第一個問題,你們有沒有試過在業(yè)務(wù)與數(shù)據(jù)層之間增加中間層,如BFF層,這樣可以更好解決定制化的上層業(yè)務(wù)問題,當(dāng)然前提是底層可以保障足夠健壯,適配多種場景的數(shù)據(jù)支撐
作者可否舉一些具體的場景案例?
作者沒時間
學(xué)到了