你寫的代碼，是別人的噩夢嗎？
從業(yè)這么多年，接觸過銀行的應(yīng)用，Apple的應(yīng)用，eBay的應(yīng)用和現(xiàn)在阿里的應(yīng)用，雖然分屬于不同的公司，使用了不同的架構(gòu)，但有一個(gè)共同點(diǎn)就是都很復(fù)雜。導(dǎo)致復(fù)雜性的原因有很多，如果從架構(gòu)的層面看，主要有兩點(diǎn)，一個(gè)是架構(gòu)設(shè)計(jì)過于復(fù)雜，層次太多能把人繞暈。另一個(gè)是根本就沒架構(gòu)，ServiceImpl作為上帝類包攬一切，一桿捅到DAO（就簡單場景而言，這種Transaction Script也還湊合，至少實(shí)現(xiàn)上手都快），這種人為的復(fù)雜性導(dǎo)致系統(tǒng)越來越臃腫，越來越難維護(hù)，醬缸的老代碼發(fā)出一陣陣惡臭，新來的同學(xué)，往往要捂著鼻子摳幾天甚至幾個(gè)月，才能理清系統(tǒng)和業(yè)務(wù)脈絡(luò)，然后又一頭扎進(jìn)各種bug fix，業(yè)務(wù)修補(bǔ)的惡性循環(huán)中，暗無天日！
CRM作為阿里最老的應(yīng)用系統(tǒng)，自然也逃不過這樣的宿命。不甘如此的我們開始反思到底是什么造成了系統(tǒng)復(fù)雜性？我們到底能不能通過架構(gòu)來治理這種復(fù)雜性？基于這個(gè)出發(fā)點(diǎn)，我們團(tuán)隊(duì)開始了一段非常有意義的架構(gòu)重構(gòu)之旅（Redefine theArch），期間我們參考了SalesForce，TMF2.0，匯金和盒馬的架構(gòu)，從他們那里汲取了很多有價(jià)值的輸入，再結(jié)合我們自己的思考最終形成了我們自己現(xiàn)在的基于擴(kuò)展點(diǎn)+元數(shù)據(jù)+CQRS+DDD的應(yīng)用架構(gòu)。該架構(gòu)的特點(diǎn)是可擴(kuò)展性好，很好的貫徹了OO思想，有一套完整的規(guī)范標(biāo)準(zhǔn)，并采用了CQRS和領(lǐng)域建模技術(shù)，在很大程度上可以降低應(yīng)用的復(fù)雜度。本文主要闡述了我們的思考過程和架構(gòu)實(shí)現(xiàn)，希望能對在路上的你有所幫助。
復(fù)雜性來自哪里？
經(jīng)過我們分析、討論，發(fā)現(xiàn)造成現(xiàn)在系統(tǒng)異常復(fù)雜的罪魁禍?zhǔn)字饕獊碜砸韵滤膫€(gè)方面：
可擴(kuò)展性差
對于只有一個(gè)業(yè)務(wù)的簡單場景，并不需要擴(kuò)展，問題也不突出，這也是為什么這個(gè)點(diǎn)經(jīng)常被忽略的原因，因?yàn)槲覀兇蟛糠值南到y(tǒng)都是從單一業(yè)務(wù)開始的。但是隨著支持的業(yè)務(wù)越來越多，代碼里面開始出現(xiàn)大量的if-else邏輯，這個(gè)時(shí)候代碼開始有壞味道，沒聞到的同學(xué)就這么繼續(xù)往上堆，聞到的同學(xué)會(huì)重構(gòu)一下，但因?yàn)橄到y(tǒng)沒有統(tǒng)一的可擴(kuò)展架構(gòu)，重構(gòu)的技法也各不相同，這種代碼的不一致性也是一種理解上的復(fù)雜度。久而久之，系統(tǒng)就變得復(fù)雜難維護(hù)。
像我們CRM應(yīng)用，有N個(gè)業(yè)務(wù)方，每個(gè)業(yè)務(wù)方又有N個(gè)租戶，如果都要用if-else判斷業(yè)務(wù)差異，那簡直就是慘絕人寰。其實(shí)這種擴(kuò)展點(diǎn)（ExtensionPoint），或者叫插件（Plug-in）的設(shè)計(jì)在架構(gòu)設(shè)計(jì)中是非常普遍的。比較成功的案例有eclipse的plug-in機(jī)制，集團(tuán)的TMF2.0架構(gòu)。還有一個(gè)擴(kuò)展性需求就是字段擴(kuò)展，這一點(diǎn)對SaaS應(yīng)用尤為重要，因?yàn)橛泻芏嗫蛻舳ㄖ苹枨?，但是我們很多系統(tǒng)也沒有統(tǒng)一的字段擴(kuò)展方案。
面向過程
是的，不管你承認(rèn)與否，很多時(shí)候，我們都是操著面向?qū)ο蟮恼Z言干著面向過程的勾當(dāng)。面向?qū)ο蟛粌H是一個(gè)語言，更是一種思維方式。在我們追逐云計(jì)算、深度學(xué)習(xí)、區(qū)塊鏈這些技術(shù)熱點(diǎn)的時(shí)候，靜下心來問問自己我們是不是真的掌握了OOD；在我們強(qiáng)調(diào)工程師要具備業(yè)務(wù)Sense，產(chǎn)品Sense，數(shù)據(jù)Sense，算法Sense，XXSense的時(shí)候，是不是忽略了對工程能力的要求。
據(jù)我觀察大部分工程師（包括我自己）的OO能力還遠(yuǎn)沒有達(dá)到精通的程度，這種OO思想的缺乏主要體現(xiàn)在兩個(gè)方面，一個(gè)是很多同學(xué)不了解SOLID原則，不懂設(shè)計(jì)模式，不會(huì)畫UML圖，或者只是知道，但從來不會(huì)運(yùn)用到實(shí)踐中；另一個(gè)是不會(huì)進(jìn)行領(lǐng)域建模，關(guān)于領(lǐng)域建模爭論已經(jīng)很多了，我的觀點(diǎn)是DDD很好，但不是銀彈，用和不用取決于場景。但不管怎樣，請你拋開偏見，好好的研讀一下EricEvans的《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》，如果有認(rèn)知升級的感悟，恭喜你，你進(jìn)階了。
我個(gè)人認(rèn)為DDD***的好處是將業(yè)務(wù)語義顯現(xiàn)化，把原先晦澀難懂的業(yè)務(wù)算法邏輯，通過領(lǐng)域?qū)ο螅―omain Object），統(tǒng)一語言（Ubiquitous Language）將領(lǐng)域概念清晰的顯性化表達(dá)出來。相信我，這種表達(dá)帶來的代碼可讀性的提升，會(huì)讓接手你代碼的人對你心懷感恩的。借用Abelson的一句話是
Programs must be written for people to read, and only incidentally for machines to execute.
所以強(qiáng)烈譴責(zé)那些不顧他人感受的編碼行為。
分層不合理
俗話說的好，All problemsin computer science can be solved by another level of indirection（計(jì)算機(jī)科學(xué)領(lǐng)域的任何問題都可以通過增加一個(gè)間接的中間層來解決），怎樣？是不是感受到間接層的強(qiáng)大了。分層***的好處就是分離關(guān)注點(diǎn)，讓每一層只解決該層關(guān)注的問題，從而將復(fù)雜的問題簡化，起到分而治之的作用。我們平時(shí)看到的MVC，pipeline，以及各種valve的模式，都是這個(gè)道理。
好吧，那是不是層次越多越好，越靈活呢。當(dāng)然不是，就像我開篇說的，過多的層次不僅不能帶來好處，反而會(huì)增加系統(tǒng)的復(fù)雜性和降低系統(tǒng)性能。就拿ISO的網(wǎng)絡(luò)七層協(xié)議來說，你這個(gè)七層分的很清楚，很好，但也很繁瑣，四層就夠了嘛。再比如我前面提到的過度設(shè)計(jì)的例子，如果沒記錯(cuò)的話應(yīng)該是Apple的Directory Service應(yīng)用，整個(gè)系統(tǒng)有7層之多，把什么validator，assembler都當(dāng)成一個(gè)層次來對待，能不復(fù)雜么。所以分層太多和沒有分層都會(huì)導(dǎo)致系統(tǒng)復(fù)雜度的上升，因此我們的原則是不可以沒有分層，但是只分有必要的層。
隨心所欲
隨心所欲是因?yàn)槿鄙僖?guī)范和約束。這個(gè)規(guī)范非常非常非常的重要（重要事情說三遍），但也是最容易被無視的點(diǎn)，其結(jié)果就是架構(gòu)的consistency被嚴(yán)重破壞，代碼的可維護(hù)性將急劇下降，國將不國，架構(gòu)將形同虛設(shè)。有同學(xué)會(huì)說不就是個(gè)naming的問題么，不就是個(gè)分包的問題么，不就是2個(gè)module還是3個(gè)module的問題么，只要功能能跑起來，這些問題都是小問題。是的，對于這些同學(xué)，我再丟給你一句名言“Just because you can, doesn't mean you should"。就拿package來說，它不僅僅是一個(gè)放一堆類的地方，更是一種表達(dá)機(jī)制，當(dāng)你將一些類放到Package中時(shí)，相當(dāng)于告訴下一位看到你設(shè)計(jì)的開發(fā)人員要把這些類放在一起考慮。
理想很豐滿，現(xiàn)實(shí)很骨感，規(guī)范的執(zhí)行是個(gè)大問題，***能在架構(gòu)層面進(jìn)行約束，例如在我們架構(gòu)中，擴(kuò)展點(diǎn)必須以ExtPt結(jié)尾，擴(kuò)展實(shí)現(xiàn)必須以Ext結(jié)尾，你不這么寫就會(huì)給你拋異常。但是架構(gòu)的約束畢竟有限，更多的還是要靠Code Review，暫時(shí)沒想到什么更好的辦法。這種對架構(gòu)約束的近似嚴(yán)苛follow，確保了系統(tǒng)的consistency，最終形成了一個(gè)規(guī)整的收納箱（如下圖所示），就像我和團(tuán)隊(duì)說的，我們在評估代碼改動(dòng)點(diǎn)時(shí)，應(yīng)該可以像Hash查找一樣，直接定位到對應(yīng)的module，對應(yīng)的package里面對應(yīng)的class。而不是到“一鍋粥”里去慢慢摳。
本章節(jié)***，上一張我們老系統(tǒng)中比較典型的代碼，也許你可以從中看到你自己應(yīng)用的影子。
復(fù)雜性應(yīng)對之道
知道了問題所在，接下來看下我們是如何一個(gè)個(gè)解決這些問題的?；仡^站在山頂再看這些解決方案時(shí)，每個(gè)都不足為奇，但當(dāng)你還“身在此山中”的時(shí)候，這個(gè)撥開層層迷霧，看到山的全貌的過程，并不是想象的那么容易。慶幸的是我團(tuán)隊(duì)在艱難跋涉之后，終有所收獲。
1、擴(kuò)展點(diǎn)設(shè)計(jì)
擴(kuò)展點(diǎn)的設(shè)計(jì)思想主要得益于TMF2.0的啟發(fā)，其實(shí)這種設(shè)計(jì)思想也一直在用，但都是在局部的代碼重構(gòu)和優(yōu)化，比如基于Strategy Pattern的擴(kuò)展，但是一直沒有找到一個(gè)很好的固化到框架中的方法。直到毗盧到團(tuán)隊(duì)分享，給了我們兩個(gè)關(guān)鍵的提示，一個(gè)是業(yè)務(wù)身份識別，用他的話說，如果當(dāng)時(shí)TMF1.0如果有身份識別的話，就沒有TMF2.0什么事了；另一個(gè)是抽象的擴(kuò)展點(diǎn)機(jī)制。
身份識別
業(yè)務(wù)身份識別在我們的應(yīng)用中非常重要，因?yàn)槲覀兊腃RM系統(tǒng)要服務(wù)不同的業(yè)務(wù)方，而且每個(gè)業(yè)務(wù)方又有多個(gè)租戶。比如中供銷售，中供拍檔，中供商家都是不同的業(yè)務(wù)方，而拍檔下的每個(gè)公司，中供商家下的每個(gè)供應(yīng)商又是不同的租戶。所以傳統(tǒng)的基于多租戶（TenantId）的業(yè)務(wù)身份識別還不能滿足我們的要求，于是在此基礎(chǔ)上我們又引入了業(yè)務(wù)碼（BizCode）來標(biāo)識業(yè)務(wù)。
所以我們的業(yè)務(wù)身份實(shí)際上是（BizCode，TenantId）二元組。在每一個(gè)業(yè)務(wù)身份下面，又可以有多個(gè)擴(kuò)展點(diǎn)（ExtensionPoint），所以一個(gè)擴(kuò)展點(diǎn)實(shí)現(xiàn)（Extension）實(shí)際上是一個(gè)三維空間中的向量。借鑒Maven Coordinate的概念我給它起了個(gè)名字叫擴(kuò)展坐標(biāo)（Extension Coordinate），這個(gè)坐標(biāo)可以用（ExtensionPoint，BizCode，TenantId）來唯一標(biāo)識。
擴(kuò)展點(diǎn)
擴(kuò)展點(diǎn)的設(shè)計(jì)是這樣的，所有的擴(kuò)展點(diǎn)（ExtensionPoint）必須通過接口申明，擴(kuò)展實(shí)現(xiàn)（Extension）是通過Annotation的方式標(biāo)注的，Extension里面使用BizCode和TenantId兩個(gè)屬性用來標(biāo)識身份，框架的Bootstrap類會(huì)在Spring啟動(dòng)的時(shí)候做類掃描，進(jìn)行Extension注冊，在Runtime的時(shí)候，通過TenantContext來選擇要使用的Extension。TenantContext是通過Interceptor在調(diào)用業(yè)務(wù)邏輯之前進(jìn)行初始化的。整個(gè)過程如下圖所示：
2、面向?qū)ο?nbsp;
領(lǐng)域建模
準(zhǔn)確的說DDD不是一個(gè)架構(gòu)，而是思想和方法論。所以在架構(gòu)層面我們并沒有強(qiáng)制約束要使用DDD，但對于像我們這樣的復(fù)雜業(yè)務(wù)場景，我們強(qiáng)烈建議使用DDD代替事務(wù)腳本（TS: Transaction Script）。因?yàn)門S的貧血模式，里面只有數(shù)據(jù)結(jié)構(gòu)，完全沒有對象（數(shù)據(jù)+行為）的概念，這也是為什么我們叫它是面向過程的原因。然而DDD是面向?qū)ο蟮模且环N知識豐富的設(shè)計(jì)（Knowledge Rich Design），怎么理解？，就是通過領(lǐng)域?qū)ο螅―omain Object），領(lǐng)域語言（Ubiquitous Language）將核心的領(lǐng)域概念通過代碼的形式表達(dá)出來，從而增加代碼的可理解性。這里的領(lǐng)域核心不僅僅是業(yè)務(wù)里的“名詞”，所有的業(yè)務(wù)活動(dòng)和規(guī)則如同實(shí)體一樣，都需要明確的表達(dá)出來。
例如前面典型代碼圖中所展示的，分配策略（DistributionPolicy）你把它隱藏在一堆業(yè)務(wù)邏輯中，沒有人知道它是干什么的，也不會(huì)把它當(dāng)成一個(gè)重要的領(lǐng)域概念去重視。但是你把它抽出來，凸顯出來，給它一個(gè)合理的命名叫DistributionPolicy，后面的人一看就明白了，哦，這是一個(gè)分配策略，這樣理解和使用起來就容易的多了，添加新的策略也更方便，不需要改原來的代碼了。
所以說好的代碼不僅要讓程序員能讀懂，還要能讓領(lǐng)域?qū)＜乙材茏x懂。再比如在CRM領(lǐng)域中，公海和私海是非常重要領(lǐng)域概念，是用來做領(lǐng)地（Territory）劃分的，每個(gè)銷售人員只能銷售私海（自己領(lǐng)地）內(nèi)的客戶，不能越界。但是在我們的代碼中卻沒有這兩個(gè)實(shí)體（Entity），也沒有相應(yīng)的語言和其對應(yīng)，這就導(dǎo)致了領(lǐng)域?qū)＜颐枋龅?，和我們?nèi)粘贤ǖ模约拔覀兡Ｐ秃痛a呈現(xiàn)的都是相互割裂的，沒有關(guān)聯(lián)性。這就給后面系統(tǒng)維護(hù)的同學(xué)造成了極大的困擾，因?yàn)樗嘘P(guān)于公海私海的操作，都是散落著各處的repeat itself的邏輯代碼，導(dǎo)致看不懂也沒辦法維護(hù)。
所以當(dāng)尚學(xué)把這兩個(gè)領(lǐng)域概念抽象成實(shí)體之后，整個(gè)模型和代碼都一下子變清晰很多。在加上上面介紹的把業(yè)務(wù)規(guī)則顯現(xiàn)化，極大的提升了代碼的可讀性和可擴(kuò)展性。用尚學(xué)的話說，用DDD寫代碼，他找到了創(chuàng)作的感覺，而不僅僅是碼農(nóng)式Coding。下圖是銷售域的簡要領(lǐng)域模型，但基本上能表達(dá)出銷售域的核心領(lǐng)域概念。
關(guān)于CQRS簡要說一下，我們只使用了Command，Query分離的概念，并沒有使用Event Sourcing，原因很簡單---不需要。關(guān)于Command的實(shí)現(xiàn)我們使用了命令模式，因此以前的ServiceImpl的職責(zé)就只是一個(gè)Facade，所有的處理邏輯都在CommandExecutor里面。
SOLID
SOLID是單一職責(zé)原則(SRP)，開閉原則(OCP)，里氏替換原則(LSP)，接口隔離原則(ISP)和依賴倒置原則(DIP)的縮寫，原則是要比模式（Design Pattern）更基礎(chǔ)更重要的指導(dǎo)準(zhǔn)則，是面向?qū)ο笤O(shè)計(jì)的Bible。深入理解后，會(huì)極大的提升我們的OOD能力和代碼質(zhì)量。比如我在開篇提到的ServiceImpl上帝類的例子，很明顯就是違背了單一職責(zé)，你一個(gè)類把所有事情都做了，把不是你的功能也往自己身上攬，所以你的內(nèi)聚性就會(huì)很差，內(nèi)聚性差將導(dǎo)致代碼很難被復(fù)用，不能復(fù)用，只能復(fù)制（Repeat Yourself），其結(jié)果就是一團(tuán)亂麻。
再比如在java應(yīng)用中使用logger框架有很多選擇，什么log4j，logback，common logging等，每個(gè)logger的API和用法都稍有不同，有的需要用isLoggable()來進(jìn)行預(yù)判斷以便提高性能，有的則不需要。對于要切換不同的logger框架的情形，就更是頭疼了，有可能要改動(dòng)很多地方。產(chǎn)生這些不便的原因是我們直接依賴了logger框架，應(yīng)用和框架的耦合性很高。
怎么破？ 遵循下依賴倒置原則就能很容易解決，依賴倒置就是你不要直接依賴我，你和我都同時(shí)依賴一個(gè)接口（所以有時(shí)候也叫面向接口的編程），這樣我們之間就解耦了，依賴和被依賴方都可以自由改動(dòng)了。
在我們的框架設(shè)計(jì)中，這種對SOLID的遵循也是隨處可見，Service Facade設(shè)計(jì)思想來自于單一職責(zé)SRP；擴(kuò)展點(diǎn)設(shè)計(jì)符合關(guān)閉原則OCP；日志設(shè)計(jì)，以及Repository和Tunnel的交互就用到了依賴倒置DIP原則，這樣的點(diǎn)還有很多，就不一一枚舉了。當(dāng)然了，SOLID不是OO的全部。抽象能力，設(shè)計(jì)模式，架構(gòu)模式，UML，以及閱讀優(yōu)秀框架源碼（我們的Command設(shè)計(jì)就是參考了Activiti的Command）也都很重要。只是SOLID更基礎(chǔ)，更重要，所以我在這里重點(diǎn)拿出來講一下，希望能得到大家的重視。
3、分層設(shè)計(jì)
這一塊的設(shè)計(jì)比較直觀，整個(gè)應(yīng)用層劃分為三個(gè)大的層次，分別是App層，Domain層和Repostiory層。
1.App層主要負(fù)責(zé)獲取輸入，組裝context，做輸入校驗(yàn)，發(fā)送消息給領(lǐng)域?qū)幼鰳I(yè)務(wù)處理，監(jiān)聽確認(rèn)消息，如果需要的話使用MetaQ進(jìn)行消息通知；
2.Domain層主要是通過領(lǐng)域服務(wù)（Domain Service），領(lǐng)域?qū)ο螅―omain Object）的交互，對上層提供業(yè)務(wù)邏輯的處理，然后調(diào)用下層Repository做持久化處理；
3.Repository層主要負(fù)責(zé)數(shù)據(jù)的CRUD操作，這里我們借用了盒馬的數(shù)據(jù)通道（Tunnel）的概念，通過Tunnel的抽象概念來屏蔽具體的數(shù)據(jù)來源，來源可以是MySQL，NoSql，Search，甚至是HSF等。
這里需要注意的是從其他系統(tǒng)獲取的數(shù)據(jù)是有界上下文（Bounded Context）下的數(shù)據(jù)，為了彌合Bounded Context下的語義Gap，通常有兩種方式，一個(gè)是用大領(lǐng)域（Big Domain）把兩邊的差異都合起來，另一個(gè)是增加防腐層（Anticorruption Layer）做轉(zhuǎn)換。什么是Bounded Context？ 簡單闡述一下，就是我們的領(lǐng)域概念是有作用范圍的（Context）的，例如搖頭這個(gè)動(dòng)作，在中國的Context下表示NO，但是在印度的Context下卻是YES。
4、規(guī)范設(shè)計(jì)
我們規(guī)范設(shè)計(jì)主要是要滿足收納原則的兩個(gè)約束：放對位置東西不要亂放，我們的每一個(gè)組件（Module），每一個(gè)包（Package）都有明確的職責(zé)定義和范圍，不可以放錯(cuò)，例如extension包就只是用來放擴(kuò)展實(shí)現(xiàn)的，不允許放其他東西，而Interceptor包就只是放攔截器的，validator包就只是放校驗(yàn)器的。我們的主要構(gòu)件如下圖所示：
貼好標(biāo)簽
東西放在合適位置后還要貼上合適的標(biāo)簽，也就是要按照規(guī)范合理命名，例如我們架構(gòu)里面和數(shù)據(jù)有關(guān)的Object，主要有Client Object，Domain Object和Data Object，Client Object是放在二方庫中和外部交互使用的DTO，其命名必須以CO結(jié)尾，相應(yīng)的Data Object主要是持久層使用的，命名必須以DO結(jié)尾。這個(gè)類名應(yīng)該是自明的（self-evident)，也就是看到類名就知道里面是干了什么事，這也就反向要求我們的類也必須是單一職責(zé)的（Single Responsibility）的，如果你做的事情不單純，自然也就很難自明了。如果我們Class Name是自明的，Package Name是自明的，Module Name也是自明的，那么我們整個(gè)應(yīng)用系統(tǒng)就會(huì)很容易被理解，看起來就會(huì)很舒服，維護(hù)效率會(huì)提高很多。我們的命名規(guī)則如下圖所示：
GTS應(yīng)用架構(gòu)
經(jīng)過上面的長篇大論，我希望我把我們的架構(gòu)理念闡述清楚了，***再從整體上看下我們的架構(gòu)吧。如果覺得不錯(cuò)，也可以把framework code拉下來自己玩一下。
整體架構(gòu)
我們的架構(gòu)原則很簡單，即在高內(nèi)聚，低耦合，可擴(kuò)展，易理解大的指導(dǎo)思想下，盡可能的貫徹OO的設(shè)計(jì)思想和原則。我們最終形成的架構(gòu)是集成了擴(kuò)展點(diǎn)+元數(shù)據(jù)+CQRS+DDD的思想，關(guān)于元數(shù)據(jù)前面沒怎么提到，這里稍微說一下，對于字段擴(kuò)展，簡單一點(diǎn)的解決方案就是預(yù)留擴(kuò)展字段，復(fù)雜一點(diǎn)的就是使用元數(shù)據(jù)引擎。
使用元數(shù)據(jù)的好處是不僅能支持字段擴(kuò)展，還提供了豐富的字段描述，等于是為以后的SaaS化配置提供了可能性，所以我們選擇了使用元數(shù)據(jù)引擎。和DDD一樣，元數(shù)據(jù)也是可選的，如果對沒有字段擴(kuò)展的需求，就不要用。***的整體架構(gòu)圖如下：
阿里高級技術(shù)專家Frank
【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
