導(dǎo)讀：COLA 的主要目的是為應(yīng)用架構(gòu)提供一套簡單的可以復(fù)制、可以理解、可以落地、可以控制復(fù)雜性的”指導(dǎo)和約束"。在實(shí)踐中作者發(fā)現(xiàn) COLA 在簡潔性上仍有不足，因此給 COLA 做了一次“升級”，在這次升級中，沒有增加任何新的功能，而是盡量多刪減了一些概念和功能阿里巴巴中文網(wǎng)站的架構(gòu)和基本功能，讓 COLA 更簡潔有效。
最近，同事告訴我，COLA 作為應(yīng)用架構(gòu)，已經(jīng)被選入阿里云的 Java 應(yīng)用初始化的應(yīng)用架構(gòu)選項(xiàng)之一。
This is ，于是，在這個(gè)里程碑節(jié)點(diǎn)上，我開始回過頭來，重新審視 COLA 一路走來的得與失。
COLA 作為一種架構(gòu)思想無疑是成功的。但是作為框架，個(gè)人感覺有點(diǎn)雞肋之嫌。特別是在簡潔性上做的不好，感覺做了不少畫蛇添足的事情。
試想一下，有些功能我作為作者都很少去使用，我實(shí)在想不到，它為什么還有存在的理由。
基于上面的思考，我做了這一次 COLA 2.0 到 COLA 3.0 的升級。在本次升級中，我沒有增加任何新的功能，而是盡量多刪減了一些概念和功能。讓 COLA 可以更加純粹的 focus 在應(yīng)用架構(gòu)上，而不是框架支持和架構(gòu)約束上。
支持我做這些決策的背后原因只有一個(gè)——奧卡姆剃刀原理。
奧卡姆剃刀原理
奧卡姆剃刀原理，是指如無必要，勿增實(shí)體（ not be ），即“簡單有效原理”。正如奧卡姆在《箴言書注》2 卷 15 題說“切勿浪費(fèi)較多東西去做，用較少的東西，同樣可以做好的事情。”
在具體的應(yīng)用過程中，我們可以遵循以下原則去做事情：
“如果同一個(gè)現(xiàn)象有 n 種理論，最簡單的那個(gè)便是最正確的。能用 n 做好事情，那就不要有第 n+1 個(gè)動作。”
比如，《皇帝的新衣》的皇帝到底穿沒穿衣服呢？如果你在現(xiàn)場，你很有可能就是大臣之一。
如果懂得了奧卡姆剃刀原理，可以用邏輯手段，判斷誰是真理。
同樣看見光身子的皇帝，第二種解釋簡單明了。而第一種解釋，可能正因?yàn)樗清e(cuò)誤的，就需要更多假設(shè)來補(bǔ)救漏洞，就像說謊圓謊一樣。
真相不需要偽裝掩飾，簡單明了。
再比如，地心說和日心說，托勒密的地心說模型是一個(gè)本輪均輪模型。人們可以按照這個(gè)模型，定量計(jì)算行星的運(yùn)動，據(jù)此推測行星所在的位置。
到了中世紀(jì)后期隨著觀察儀器的不斷改進(jìn)，人們能夠更加精確地測量出行星的位置和運(yùn)動，觀測到行星實(shí)際位置與這個(gè)模型的計(jì)算結(jié)果存在偏差，一開始還能勉強(qiáng)應(yīng)付，后來小本輪增加到八十多個(gè)，卻仍然不能精確地計(jì)算出行星的準(zhǔn)確位置。
1543 年，波蘭天文學(xué)家哥白尼在臨終時(shí)發(fā)表了一部具有歷史意義的著作——《天體運(yùn)行論》。這個(gè)理論體系提出了一個(gè)明確的觀點(diǎn)：太陽是宇宙的中心，一切行星都在圍繞太陽旋轉(zhuǎn)。該理論認(rèn)為，地球也是行星之一，它一方面像陀螺一樣自轉(zhuǎn)，一方面又和其他行星一樣圍繞太陽轉(zhuǎn)動。
哥白尼的計(jì)算不僅結(jié)構(gòu)嚴(yán)謹(jǐn)，而且計(jì)算簡單，與已經(jīng)加到八十余個(gè)圈的地心說相比，哥白尼的計(jì)算與實(shí)際觀測資料能更好地吻合。因此，地心說最終被日心說所取代。
設(shè)計(jì)中的彎彎繞
深入考察一下，我們系統(tǒng)中，類似于“地心說”這樣的彎彎繞的設(shè)計(jì)，實(shí)在是不在少數(shù)。
從系統(tǒng)架構(gòu)的角度看，有些彎彎繞是因?yàn)橄到y(tǒng)邊界劃分不合理，導(dǎo)致職責(zé)不清，依賴混亂。
從應(yīng)用架構(gòu)的角度看，有些彎彎繞是因?yàn)檫^度設(shè)計(jì)阿里巴巴中文網(wǎng)站的架構(gòu)和基本功能，為了追求所謂的靈活性和可擴(kuò)展性，使用了不恰當(dāng)?shù)脑O(shè)計(jì)。導(dǎo)致本來可以直觀呈現(xiàn)的代碼邏輯，被各種包裝，各種隱藏，各種轉(zhuǎn)發(fā).... 無形中極大的阻礙了代碼的可讀性和可理解性，增加了維護(hù)成本。
舉個(gè)例子，我看過無數(shù)的業(yè)務(wù)系統(tǒng)，喜歡拿業(yè)務(wù)流程編排說事情。因此，在業(yè)務(wù)系統(tǒng)中，可以看到各種五花八門的“彎彎繞設(shè)計(jì)”。
比如，在一個(gè)業(yè)務(wù)系統(tǒng)中，我看到了如下的 設(shè)計(jì)。這個(gè)設(shè)計(jì)的本質(zhì)是說把一個(gè)復(fù)雜的業(yè)務(wù)操作進(jìn)行結(jié)構(gòu)化拆解為多個(gè)小的處理單元。
拆解是正確的，但是這種處理方式顯然不夠“奧卡姆”（關(guān)于更多結(jié)構(gòu)化分解的內(nèi)容，可以看我的另一篇文章：如何寫復(fù)雜業(yè)務(wù)代碼？）。作為維護(hù)人員，進(jìn)入“入口函數(shù)”后，還要去查數(shù)據(jù)庫，然后才能知道哪些組件被調(diào)用了，太繞了，不夠直觀，也不簡潔。
同樣的邏輯，按照下面的方式寫不香嗎？
public class CreateCSPUExecutor {
@Resource
private InitContextStep initContextStep;
@Resource
private CheckRequiredParamStep checkRequiredParamStep;
@Resource
private CheckUnitStep checkUnitStep;
@Resource
private CheckExpiringDateStep checkExpiringDateStep;
@Resource
private CheckBarCodeStep checkBarCodeStep;
@Resource
private CheckBarCodeImgStep checkBarCodeImgStep;
@Resource
private CheckBrandCategoryStep checkBrandCategoryStep;
@Resource
private CheckProductDetailStep checkProductDetailStep;
@Resource
private CheckSpecImgStep checkSpecImgStep;
@Resource
private CreateCSPUStep createCSPUStep;
@Resource
private CreateCSPULogStep createCSPULogStep;
@Resource
private SendCSPUCreatedEventStep sendCSPUCreatedEventStep;
public Long create(MyCspuSaveParam myCspuSaveParam){
SaveCSPUContext context = initContextStep.initContext(myCspuSaveParam);
checkRequiredParamStep.check(context);
checkUnitStep.check(context);
checkExpiringDateStep.check(context);
checkBarCodeStep.check(context);
checkBarCodeImgStep.check(context);
checkBrandCategoryStep.check(context);
checkProductDetailStep.check(context);
checkSpecImgStep.check(context);
createCSPUStep.create(context);
createCSPULogStep.log(context);
sendCSPUCreatedEventStep.sendEvent(context);
return context.getCspu().getId();
}
}
public class CreateCSPUExecutor {
@Resource
private InitContextStep initContextStep;
@Resource
private CheckRequiredParamStep checkRequiredParamStep;
@Resource
private CheckUnitStep checkUnitStep;
@Resource
private CheckExpiringDateStep checkExpiringDateStep;
@Resource
private CheckBarCodeStep checkBarCodeStep;
@Resource
private CheckBarCodeImgStep checkBarCodeImgStep;
@Resource
private CheckBrandCategoryStep checkBrandCategoryStep;
@Resource
private CheckProductDetailStep checkProductDetailStep;
@Resource
private CheckSpecImgStep checkSpecImgStep;
@Resource
private CreateCSPUStep createCSPUStep;
@Resource
private CreateCSPULogStep createCSPULogStep;
@Resource
private SendCSPUCreatedEventStep sendCSPUCreatedEventStep;
public Long create(MyCspuSaveParam myCspuSaveParam){
SaveCSPUContext context = initContextStep.initContext(myCspuSaveParam);
checkRequiredParamStep.check(context);
checkUnitStep.check(context);
checkExpiringDateStep.check(context);
checkBarCodeStep.check(context);
checkBarCodeImgStep.check(context);
checkBrandCategoryStep.check(context);
checkProductDetailStep.check(context);
checkSpecImgStep.check(context);
createCSPUStep.create(context);
createCSPULogStep.log(context);
sendCSPUCreatedEventStep.sendEvent(context);
return context.getCspu().getId();
}
}這種寫法簡單直觀，易維護(hù)，與前一種方式相比，具有同樣的組件復(fù)用性。符合奧卡姆剃刀的精神，相比較而言，前面那種彎彎繞設(shè)計(jì)，雖然看起來有點(diǎn)設(shè)計(jì)感，帶來了一點(diǎn)點(diǎn) OCP 的好處。但是無端增加了理解和認(rèn)知成本，孰優(yōu)孰劣，不難分辨。
COLA 3.0 升級
做了這么長的鋪墊，終于到了批斗 COLA 中“彎彎繞設(shè)計(jì)”的時(shí)候了。
1. 去掉
在 COLA 的初始階段，因?yàn)槭艿?CQRS 的影響，于是想到了使用命令模式來處理用戶請求。設(shè)計(jì)的初衷是想通過框架，一方面強(qiáng)制約束 和 Query 的處理方式，另一方面把 里面的邏輯，強(qiáng)制拆分到 中去，防止 膨脹過快。
和上面介紹過的 設(shè)計(jì)類似，這種設(shè)計(jì)有點(diǎn)繞，不夠直觀，如下所示：
public class MetricsServiceImpl implements MetricsServiceI{
@Autowired
private CommandBusI commandBus;
@Override
public Response addATAMetric(ATAMetricAddCmd cmd) {
return commandBus.send(cmd);
}
@Override
public Response addSharingMetric(SharingMetricAddCmd cmd) {
return commandBus.send(cmd);
}
@Override
public Response addPatentMetric(PatentMetricAddCmd cmd) {
return commandBus.send(cmd);
}
@Override
public Response addPaperMetric(PaperMetricAddCmd cmd) {
return commandBus.send(cmd);
}
}看起來還挺干凈的，可是 到底是被哪個(gè) 處理的呢，不直觀。我還要去理解 ，以及 是如何注冊 的。無形中增加了認(rèn)知成本，不好。
既然這樣，為何不用奧卡姆剃刀把這個(gè) 剔除呢。如下所示，去除 之后，代碼是不是直觀了很多，唯一的損失是我們會失去框架層面提供的 功能，然而， 正是我下一個(gè)要動刀的地方。
public class MetricsServiceImpl implements MetricsServiceI{
@Resource
private ATAMetricAddCmdExe ataMetricAddCmdExe;
@Resource
private SharingMetricAddCmdExe sharingMetricAddCmdExe;
@Resource
private PatentMetricAddCmdExe patentMetricAddCmdExe;
@Resource
private PaperMetricAddCmdExe paperMetricAddCmdExe;
@Override
public Response addATAMetric(ATAMetricAddCmd cmd) {
return ataMetricAddCmdExe.execute(cmd);
}
@Override
public Response addSharingMetric(SharingMetricAddCmd cmd) {
return sharingMetricAddCmdExe.execute(cmd);
}
@Override
public Response addPatentMetric(PatentMetricAddCmd cmd) {
return patentMetricAddCmdExe.execute(cmd);
}
@Override
public Response addPaperMetric(PaperMetricAddCmd cmd) {
return paperMetricAddCmdExe.execute(cmd);
}
}2. 去掉
當(dāng)時(shí)設(shè)計(jì) ，是因?yàn)橛? 作為基礎(chǔ)，為了更好的利用命令模式帶來的好處，便添加了 功能。其本質(zhì)是一個(gè) AOP 處理。
鑒于 的 AOP 功能已經(jīng)很完善了，這個(gè)設(shè)計(jì)也是有點(diǎn)雞肋。事實(shí)證明，大家在使用 COLA 框架的時(shí)候，很少會使用 ，包括我自己也是一樣。既然如此，剔除也罷。
3. 去掉 、、
關(guān)于命名的重要性，這里就不贅述了。當(dāng)時(shí)想著是否能從框架層面，規(guī)范一下一些常用功能的命名。但是在實(shí)際使用中，發(fā)現(xiàn)這個(gè)想法也是有些過于理想化了。
我記得，在團(tuán)隊(duì)實(shí)踐 COLA 的初期，還經(jīng)常為什么是 （轉(zhuǎn)換器），什么是 （組裝器）的事情，爭論不休。
后面我仔細(xì)想了想，命名雖然很重要，但其作用域最多也就是一個(gè)團(tuán)隊(duì)規(guī)范，你校驗(yàn)器是叫 還是 并沒有什么本質(zhì)區(qū)別，團(tuán)隊(duì)自己定義就好了。嘗試從框架層面去解決團(tuán)隊(duì)約定問題，其效果不會太好，因此也果斷揮刀剔除。
4. 類掃描優(yōu)化
業(yè)務(wù)身份和擴(kuò)展點(diǎn)的思想，是 TMF 的核心理念，也是阿里業(yè)務(wù)中臺的進(jìn)行多業(yè)務(wù)支持的核心方法論。
COLA 致力于提供一種輕量級的擴(kuò)展實(shí)現(xiàn)方式，因此該功能在奧卡姆的屠刀下得以保存。因?yàn)?COLA 的擴(kuò)展點(diǎn)設(shè)計(jì)是借鑒了中臺的 TMF，因此在前面的設(shè)計(jì)中，其類掃描方案是直接照搬 TMF 的做法。
實(shí)際上，TMF 的類掃描方案對 COLA 來說有點(diǎn)多余。因?yàn)?COLA 本身就是架設(shè)在 的基礎(chǔ)之上，而 又是建立在類掃描的基礎(chǔ)之上。因此，我們完全可以復(fù)用 的類掃描，沒必要自己寫一套。
在原生的 中，至少有 3 種方式可以獲取到用戶自定義 的 Bean，最簡潔的是通過 .on 方法，或者使用 der 進(jìn)行掃包。
在這次改版中，我選用的是 on 方法，主要是為了獲取 @ 的 Bean，用來實(shí)現(xiàn)擴(kuò)展點(diǎn)功能，廢棄了原來的 TMF 類掃描實(shí)現(xiàn)。
總結(jié)
觸發(fā)這次升級的動機(jī)，主要是因?yàn)椋约涸趯?shí)踐 COLA 的過程中，的確發(fā)現(xiàn)有些華而不實(shí)的功能。在 COLA 作為阿里云的基礎(chǔ)應(yīng)用架構(gòu)，其影響力越來越大的時(shí)候，我有責(zé)任給到大家一個(gè)正確的引導(dǎo)——去偽存真，簡潔有效，而不是引入更多的復(fù)雜度。
實(shí)際上，COLA 是由兩部分組成的：
一方面 COLA 是一種架構(gòu)思想，是整合了洋蔥圈架構(gòu)、適配器架構(gòu)、DDD、整潔架構(gòu)、TMF 等架構(gòu)思想的一種應(yīng)用架構(gòu)。
在這次升級中，架構(gòu)思想部分基本沒有變化，唯一一點(diǎn)是因?yàn)槿コ? 概念，因此 CQRS 也成了可選項(xiàng)，而不再是一種強(qiáng)要求。
另一方面 COLA 也是框架組件，通過這次升級，我使用奧卡姆剃刀砍掉了絕大部分的組件能力，僅僅保留了擴(kuò)展點(diǎn)功能。其用意是不希望 COLA 作為框架給到應(yīng)用開發(fā)者太多的約束，這不符合簡單有效的風(fēng)格。
所以，總結(jié)下來，與其說這是一次升級，不如說它是功能“降級”，是在做減法。
但我相信，減法可以讓 COLA 更加符合奧卡姆精神，幫助 COLA 輕裝上陣，走的更遠(yuǎn)。
COLA 開源地址：//COLA
阿里云 JAVA 應(yīng)用腳手架
是基于 - 實(shí)現(xiàn)的工程腳手架生成平臺，開發(fā)者們只需要添加一些注解和少量配置，就可以快速搭建分布式應(yīng)用系統(tǒng)，它使用更親切的中文，也不會有網(wǎng)絡(luò)延遲問題，最重要的是提供更多本地化的組件依賴。
點(diǎn)擊鏈接，立即體驗(yàn)阿里云 JAVA 應(yīng)用腳手架：/?=
“阿里巴巴云原生關(guān)注微服務(wù)、、容器、 Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的公眾號。”