最近幾年，中臺(tái)之風(fēng)盛行，各行各業(yè)都希望能建設(shè)自己的”大中臺(tái)，小前臺(tái)“，期望能夠通過(guò)強(qiáng)大中臺(tái)的復(fù)用能力快速的賦能業(yè)務(wù)，讓新業(yè)務(wù)可以快速試錯(cuò)，降低整體成本，但是實(shí)踐下來(lái)發(fā)現(xiàn)困難重重。剛好最近在參與一個(gè)跨域功能點(diǎn)的復(fù)用開(kāi)發(fā)，借此梳理下軟件架構(gòu)中復(fù)用的一種路徑。

最開(kāi)始不同業(yè)務(wù)為了快速成長(zhǎng)，一般都是在各自的系統(tǒng)中開(kāi)發(fā)，例如三個(gè)電商業(yè)務(wù)A、B、C會(huì)有各自的交易、支付、商品等完整的電商系統(tǒng)。

各自生長(zhǎng)

隨著公司的發(fā)展，發(fā)現(xiàn)各個(gè)業(yè)務(wù)之間有很多公共的特性，如果還是在各自系統(tǒng)中單獨(dú)實(shí)現(xiàn)，不利于能力的復(fù)用與沉淀，另外還有一些其他因素的考慮（例如打造公司生態(tài)系統(tǒng)，打通不同業(yè)務(wù)線的數(shù)據(jù)壁壘），于是慢慢將公共的功能抽取出來(lái)形成了底層平臺(tái)，例如交易平臺(tái)，支付平臺(tái)。

平臺(tái)型

平臺(tái)型解決了復(fù)用了問(wèn)題，但是卻面臨了擴(kuò)展（定制）的問(wèn)題，每個(gè)業(yè)務(wù)之間都存在不同的玩法，業(yè)務(wù)邏輯存在較大的差異，例如業(yè)務(wù)A在計(jì)算訂單金額時(shí)需要增加費(fèi)用PA1，于是A在生成訂單的接口中增加了一個(gè)額外費(fèi)用的參數(shù)PA1。

金額計(jì)算邏輯

隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)A中對(duì)于金額的計(jì)算發(fā)生了變化，增加的金額變成了2*PA1，但是當(dāng)業(yè)務(wù)方開(kāi)發(fā)修改時(shí)，不敢直接在之前的定制邏輯中修改，因?yàn)椴恢绤?shù)PA1到底被多少業(yè)務(wù)方使用了（很可能業(yè)務(wù)方B也使用了這個(gè)參數(shù)），因此這個(gè)時(shí)候往往再增加一個(gè)參數(shù)或者增加一層判斷。

定制增加后的金額計(jì)算

底層平臺(tái)中的各種定制點(diǎn)越來(lái)越多，邏輯越來(lái)越復(fù)雜，很難有人能夠通過(guò)代碼就知道業(yè)務(wù)流程是如何運(yùn)行的，在新增需求時(shí)，只能通過(guò)不斷的增加補(bǔ)丁的方式來(lái)實(shí)現(xiàn)，原來(lái)的代碼沒(méi)人敢改動(dòng)。結(jié)果就是中臺(tái)的響應(yīng)越來(lái)越慢，效能越來(lái)越低，低效貫穿了整個(gè)研發(fā)過(guò)程，包括需求評(píng)審與設(shè)計(jì)（無(wú)法準(zhǔn)確評(píng)估系統(tǒng)的樣子，只能先去試試看），功能開(kāi)發(fā)，測(cè)試（隨便一些小改動(dòng)都需要大量回歸驗(yàn)證，以免影響到其他業(yè)務(wù)），發(fā)布以及線上維護(hù)。

了解設(shè)計(jì)模式的都知道可以通過(guò)策略模式來(lái)將不同的定制邏輯放到專(zhuān)屬的地方，但是這樣只是代碼結(jié)構(gòu)好看些，問(wèn)題的關(guān)鍵是定制邏輯沒(méi)有統(tǒng)一的判斷邏輯，無(wú)法知道某個(gè)業(yè)務(wù)方會(huì)使用哪種策略。為了解決這個(gè)問(wèn)題，于是引入了統(tǒng)一判斷邏輯：業(yè)務(wù)身份。為每個(gè)業(yè)務(wù)方分配一個(gè)業(yè)務(wù)身份，并且強(qiáng)制所有定制邏輯都必須根據(jù)身份來(lái)區(qū)分差異，并且將差異放到每個(gè)業(yè)務(wù)的專(zhuān)屬地方，業(yè)務(wù)方只能修改專(zhuān)屬代碼。

金額計(jì)算業(yè)務(wù)定制

將所有的業(yè)務(wù)方的訂正邏輯都放置到業(yè)務(wù)的專(zhuān)屬代碼塊中就形成了下面的結(jié)構(gòu)。

具有定制功能的平臺(tái)

重構(gòu)之后的平臺(tái)難點(diǎn)在于如何制定定制點(diǎn)，如果定制點(diǎn)的粒度太大，把整個(gè)金額計(jì)算邏輯全部扔給業(yè)務(wù)方定制，就失去了平臺(tái)的功能，沒(méi)有了復(fù)用的價(jià)值，如果定制點(diǎn)粒度太小，對(duì)于業(yè)務(wù)方開(kāi)發(fā)來(lái)說(shuō)理解成本較大，看到的都是一個(gè)個(gè)離散的點(diǎn)，無(wú)法感知整體邏輯。

為了實(shí)現(xiàn)功能的復(fù)用以及擴(kuò)展點(diǎn)過(guò)多的問(wèn)題，于是在業(yè)務(wù)定制上面增加不同場(chǎng)景下默認(rèn)實(shí)現(xiàn)，例如業(yè)務(wù)A與業(yè)務(wù)C都支持紅包，那么A與C中就需要定制一份與紅包相關(guān)的邏輯，這里紅包的邏輯就可以當(dāng)成一個(gè)默認(rèn)往上抽取一層，然后基于這個(gè)默認(rèn)實(shí)現(xiàn)再制定業(yè)務(wù)定制點(diǎn)，業(yè)務(wù)A與業(yè)務(wù)C修改這層默認(rèn)定制點(diǎn)就好了。

具有定制以及復(fù)用沉淀的平臺(tái)

系統(tǒng)到這個(gè)階段已經(jīng)越來(lái)越復(fù)雜了，業(yè)務(wù)混亂的問(wèn)題解決了，被隔離到了業(yè)務(wù)自己的代碼塊中了，但是系統(tǒng)本身層次的增加，對(duì)于代碼的閱讀與理解帶來(lái)了很大的成本，代碼的流程不斷在不同的層級(jí)之間切換，模型也不斷的轉(zhuǎn)換，跟操作系統(tǒng)中的系統(tǒng)調(diào)用一樣，第一次看完第二次基本也不記得了，而對(duì)于業(yè)務(wù)方來(lái)說(shuō)定制點(diǎn)的理解也是只知其一不知其二，萬(wàn)一不幸現(xiàn)有的定制點(diǎn)不能滿(mǎn)足業(yè)務(wù)述求，那更是傷筋動(dòng)骨。

對(duì)于復(fù)用與定制本來(lái)就是一個(gè)平衡與取舍，如果提供的是大而全的功能，就會(huì)給定制帶來(lái)困難，上面的平臺(tái)解決方案就是基于這種模型，在對(duì)外大接口下不斷尋求定制的方案，同時(shí)也要能盡量的提高復(fù)用度；另外一種方案就是提供原子能力，然后根據(jù)需求去進(jìn)行組裝，然后再根據(jù)業(yè)務(wù)的共性進(jìn)行沉淀。

自上而下的業(yè)務(wù)定制

復(fù)用與擴(kuò)展雖然很難，但是值得探索，去找到一條可以快速支撐業(yè)務(wù)以及減少資源投入的解決方案。