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