component是什么接口_阿里高级技术专家：整洁的应用架构“长”什么样？
很多同學(xué)不止一次和我反饋，我們的系統(tǒng)很混亂，主要表現(xiàn)在：
- 應(yīng)用的層次結(jié)構(gòu)混亂：不知道應(yīng)用應(yīng)該如何分層、應(yīng)該包含哪些組件、組件之間的關(guān)系是什么；
- 缺少規(guī)范的指導(dǎo)和約束：新加一段業(yè)務(wù)邏輯不知道放在什么地方（哪個(gè)類，哪個(gè)包）、應(yīng)該起什么名字比較合適？
解決這些問(wèn)題，正是我創(chuàng)建COLA（https://github.com/alibaba/COLA）的初心之一——試圖探索一套切實(shí)可行的應(yīng)用架構(gòu)規(guī)范，這個(gè)規(guī)范不是高高在上的紙上談兵，而是可以復(fù)制、可以理解、可以落地、可以控制復(fù)雜性的指導(dǎo)和約束。
自從COLA誕生以來(lái)，我收到了很多的意見(jiàn)和建議。同時(shí)，我自己在實(shí)踐過(guò)程中，也發(fā)現(xiàn)COLA 1.0的諸多不足，有些設(shè)計(jì)是冗余的并不是很有必要，而有些關(guān)鍵要素并沒(méi)有囊括。譬如，我最近在思考的應(yīng)用架構(gòu)核心和復(fù)雜業(yè)務(wù)代碼治理就是對(duì)COLA 1.0的反思。
結(jié)合實(shí)踐中的探索和對(duì)復(fù)雜度治理持續(xù)的思考，我決定對(duì)COLA進(jìn)行一次全面的升級(jí)，于是有了現(xiàn)在的COLA 2.0。
從1.0到2.0，不僅僅是數(shù)字的簡(jiǎn)單變化，更是架構(gòu)理念和設(shè)計(jì)理念的升級(jí)，其主要變動(dòng)點(diǎn)包括：
- 新架構(gòu)分層：Domain層不再直接依賴Infrastructure層。
- 新組件劃分：對(duì)組件進(jìn)行了重新定義和劃分，加了新組件，去除了一些老組件（Validator，Convertor等）。
- 新擴(kuò)展點(diǎn)設(shè)計(jì)：引入了新概念，讓擴(kuò)展更加靈活。
- 新二方庫(kù)定位：二方庫(kù)不僅僅是DTO，也是Domain Model的輕量級(jí)表達(dá)和實(shí)現(xiàn)。
新架構(gòu)分層
在COLA 1.0中，我們的分層是如下圖所示的經(jīng)典分層結(jié)構(gòu)：
在COLA 2.0中，還是這些層次，但是依賴關(guān)系發(fā)生了變化，Domain層不再直接依賴Infrastructure層，而是引入了一個(gè)Gateway的概念，使用DIP（Dependency Inversion Principle，依賴倒置）反轉(zhuǎn)了Domain層和Infrastructure層的依賴關(guān)系，其關(guān)系如下圖所示：
這樣做的好處是Domain層會(huì)變得更加純粹，完全擺脫了對(duì)技術(shù)細(xì)節(jié)（以及技術(shù)細(xì)節(jié)帶來(lái)的復(fù)雜度）的依賴，只需要安心處理業(yè)務(wù)邏輯就好了。
除此之外，還有兩個(gè)好處：
1. 并行開(kāi)發(fā)：只要在Domain和Infrastructure之間約定好接口，可以有兩個(gè)同學(xué)并行編寫Domain和Infrastructure的代碼。
2. 可測(cè)試性：沒(méi)有任何依賴的Domain里面都是POJO的類，單元測(cè)試將會(huì)變得非常方便，也非常適合TDD的開(kāi)發(fā)。
新組件劃分
模塊和組件的定義
首先，先明確一下組件（Component）這個(gè)概念的定義，組件在Java中（或者說(shuō)在本文中），其范圍就是Java的包（Package）。
還有一個(gè)詞叫模塊（Module），組件和模塊這兩個(gè)概念是比較容易發(fā)生混淆的。比如在《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中，作者就說(shuō)：
If you are using Java or C#, you are already familiar with Modules, though you know them by another name. Java calls them packages. C# calls them namespaces.他認(rèn)為Module是Package，我認(rèn)為這個(gè)定義容易造成混淆。特別是在使用Maven的時(shí)候，在Maven中，Module是一個(gè)Artifact，通常是一個(gè)Jar而不是Package。比如COLA Framework就包括如下四個(gè)Module：
<modules><module>cola-common</module><module>cola-core</module><module>cola-extension</module><module>cola-test</module> </modules>的確，Module和Component這兩個(gè)概念很相近，很容易造成混淆。比如，在StackOverflow上有一個(gè)提問(wèn)【1】，就是問(wèn)Module和Component之間區(qū)別的。獲得最高贊的答案是通過(guò)Scope來(lái)區(qū)分的。
The terms are similar. I generally think of a "module" as being larger than a "component". A component is a single part, usually relatively small in scope.這個(gè)回答和我的直覺(jué)反應(yīng)是一致的，即Module比Component要大。根據(jù)以上信息，我在此對(duì)Module和Component進(jìn)行一下定義說(shuō)明，在本文中，都會(huì)遵照如下的定義和Notation（表示法）。
- 模塊（Module）：和Maven中Module定義保持一致，簡(jiǎn)單理解就是Jar。用正方體表示。
- 組件（Component）：和UML中的定義類似，簡(jiǎn)單理解就是Package。用UML的組件圖表示。
一個(gè)Moudle通常是由多個(gè)Component組成的，其關(guān)系和表示法如下圖所示：
COLA 2.0的組件
在COLA 2.0中，我們重新設(shè)計(jì)了組件，引入了一些新的組件，也去除了一些舊組件。這些變動(dòng)的宗旨是為了讓應(yīng)用結(jié)構(gòu)更加清晰，組件的職責(zé)更加明確，從而更好的提供開(kāi)發(fā)指導(dǎo)和約束。
新的組件結(jié)構(gòu)如下圖所示：
這些組件各自都有自己的職責(zé)范圍，組件的職責(zé)是COLA的重要組成部分，也就是我們上面說(shuō)的“指導(dǎo)和約束”。這些組件的詳細(xì)職責(zé)描述如下：
1、二方庫(kù)里的組件：
- api：存放的是應(yīng)用對(duì)外的接口。
- dto.domainmodel：用來(lái)做數(shù)據(jù)傳輸?shù)妮p量級(jí)領(lǐng)域?qū)ο蟆?/li>
- dto.domainevent: 用來(lái)做數(shù)據(jù)傳輸?shù)念I(lǐng)域事件。
2、Application里的組件：
- service：接口實(shí)現(xiàn)的facade，沒(méi)有業(yè)務(wù)邏輯，可以包含對(duì)不同終端的adapter。
- eventhandler：處理領(lǐng)域事件，包括本域的和外域的。
- executor：用來(lái)處理命令（Command）和查詢（Query），對(duì)復(fù)雜業(yè)務(wù)，可以包含Phase和Step。
- interceptor: COLA提供的對(duì)所有請(qǐng)求的AOP處理機(jī)制。
3、Domain里的組件：
- domain：領(lǐng)域?qū)嶓w，允許繼承domainmodel。
- domainservice: 領(lǐng)域服務(wù)，用來(lái)提供更粗粒度的領(lǐng)域能力。
- gateway：對(duì)外依賴的網(wǎng)關(guān)接口，包括存儲(chǔ)、RPC、Search等。
4、Infrastructure里的組件：
- config：配置信息相關(guān)。
- message：消息處理相關(guān)。
- repository：存儲(chǔ)相關(guān)，是gateway的特化，主要用來(lái)做本域的數(shù)據(jù)CRUD操作。
- gateway：對(duì)外依賴的網(wǎng)關(guān)接口（Domain里的gateway）的實(shí)現(xiàn)。
在使用COLA的時(shí)候，請(qǐng)盡量按照組件規(guī)范約束去構(gòu)建我們的應(yīng)用。這樣可以讓我們的應(yīng)用結(jié)構(gòu)清晰、有章可循。如此這般，代碼的可維護(hù)性和可理解性會(huì)得到極大的提升。
新擴(kuò)展點(diǎn)設(shè)計(jì)
引入新概念
在討論之前，我們先來(lái)明確一下在COLA2.0擴(kuò)展設(shè)計(jì)中引入的新概念：業(yè)務(wù)、用例、場(chǎng)景。
- 業(yè)務(wù)（Business）：就是一個(gè)自負(fù)盈虧的財(cái)務(wù)主體，比如tmall、淘寶和零售通就是三個(gè)不同的業(yè)務(wù)。
- 用例（Use Case）：描述了用戶和系統(tǒng)之間的互動(dòng)，每個(gè)用例提供了一個(gè)或多個(gè)場(chǎng)景。比如，支付訂單就是一個(gè)典型的用例。
- 場(chǎng)景（Scenario）：場(chǎng)景也被稱為用例的實(shí)例（Instance），包括用例所有的可能情況（正常的和異常的）。比如對(duì)于“訂單支付”這個(gè)用例，就有“可以使用花唄”，“支付寶余額不足”，“銀行賬戶余額不足”等多個(gè)場(chǎng)景。
簡(jiǎn)單來(lái)說(shuō)，就是一個(gè)業(yè)務(wù)是有多個(gè)用例組成的，一個(gè)用例是有多個(gè)場(chǎng)景組成的。用淘寶做一個(gè)簡(jiǎn)單示例，業(yè)務(wù)、用例和場(chǎng)景的關(guān)系如下：
新擴(kuò)展點(diǎn)的實(shí)現(xiàn)
在COLA 2.0中，擴(kuò)展的實(shí)現(xiàn)機(jī)制沒(méi)有變化，主要變化就在于上文中引入的新概念。因?yàn)镃OLA 1.0的擴(kuò)展設(shè)計(jì)思想來(lái)自于星環(huán)，所以當(dāng)初的擴(kuò)展粒度也是copy了星環(huán)的“業(yè)務(wù)身份”。COLA 1.0的擴(kuò)展定位的方法如下圖所示：
然而，在實(shí)際工作中，能像星環(huán)那樣支撐多個(gè)業(yè)務(wù)的場(chǎng)景并不常見(jiàn)。更多是對(duì)不用用例，或是對(duì)同一個(gè)用例不同場(chǎng)景的差異化支持。比如“創(chuàng)建商品”和“更新商品”是兩個(gè)用例，但是大部分的業(yè)務(wù)代碼是可以復(fù)用的，只有一小部分需要差異化處理。
為了支持這種更細(xì)粒度的擴(kuò)展支持，除了之前的“業(yè)務(wù)身份（BizId）”之外，我還引入了Use Case和Scenario這兩個(gè)概念。新的擴(kuò)展定位如下圖所示：
可以看到，在新的擴(kuò)展框架下，原來(lái)只能支持到“業(yè)務(wù)身份”的擴(kuò)展，現(xiàn)在可以支持到“業(yè)務(wù)身份”，“用例”，“場(chǎng)景”的三級(jí)擴(kuò)展，無(wú)疑比以前要靈活的多，并且在表達(dá)和可理解性上也比以前好。
在新的擴(kuò)展框架下，例如我們實(shí)現(xiàn)上圖中所展示的擴(kuò)展：在tmall這個(gè)業(yè)務(wù)下——的下單用例——的88VIP場(chǎng)景——的用戶身份校驗(yàn)進(jìn)行擴(kuò)展，我們只需要聲明一個(gè)如下的擴(kuò)展實(shí)現(xiàn)（Extension）就可以了。
新二方庫(kù)定位
關(guān)于二方庫(kù)的定位表面上來(lái)看，是一個(gè)簡(jiǎn)單問(wèn)題，因?yàn)榉?wù)的二方庫(kù)無(wú)外乎就是用來(lái)暴露接口和傳遞數(shù)據(jù)的（DTO）。不過(guò)，往深層次思考，它并不是一個(gè)簡(jiǎn)單的問(wèn)題，因?yàn)樗婕暗讲煌缦奚舷挛?#xff08;Bounded Context）之間的協(xié)作問(wèn)題。它是分布式環(huán)境下，不同服務(wù)（SOA，RPC，微服務(wù)，叫法不同，本質(zhì)一樣）之間如何協(xié)作的重要架構(gòu)設(shè)計(jì)問(wèn)題。
Bounded Context之間的協(xié)作
如何實(shí)現(xiàn)不同域之間的協(xié)作，同時(shí)又要保證各自領(lǐng)域的概念的完整性是有一套方法論的。總體來(lái)說(shuō)，大概有兩種方式：共享內(nèi)核（Shared Kernel）和防腐層（ACL，Anti-Corruption Layer）。
1. 共享內(nèi)核（Shared Kernel）
It’s possible that only one of the teams will maintain the code, build, and test for what is shared. A Shared Kernel is often very difficult to conceive in the first place, and difficult to maintain, because you must have open communication between teams and constant agreement on what constitutes the model to be shared.上面是引用《DDD Distilled》（作者是Vaughn Vernon）關(guān)于Shared Kernel描述的原話，其優(yōu)點(diǎn)是Share（減少重復(fù)建設(shè)），其缺點(diǎn)也是Share（團(tuán)隊(duì)之間緊耦合）。
2. 防腐層（ACL，Anti-Corruption Layer）
An Anticorruption Layer is the most defensive Context Mapping relationship, where the downstream team creates a translation layer between its Ubiquitous Language (model) and the Ubiquitous Language (model) that is upstream to it.同樣是來(lái)自于《DDD Distilled》, 防腐層是隔離最徹底的做法，其優(yōu)點(diǎn)是沒(méi)有Share（完全解耦，各自獨(dú)立），其缺點(diǎn)也是沒(méi)有Share（有一定的轉(zhuǎn)換成本）。
不過(guò)我和Vernon的觀點(diǎn)差不多，都比較贊成防腐層的做法。因?yàn)樵黾拥恼Z(yǔ)義轉(zhuǎn)換陳本，相較于系統(tǒng)的可維護(hù)性和可理解性而言，是完全值得的。
Whenever possible, you should try to create an Anticorruption Layer between your downstream model and an upstream integration model, so that you can produce model concepts on your side of the integration that specifically fit your business needs and that keep you completely isolated from foreign concepts.二方庫(kù)的重新定位
在大部分情況下，二方庫(kù)的確是用來(lái)定義服務(wù)接口和數(shù)據(jù)協(xié)議的。但是二方庫(kù)區(qū)別于JSON的地方是它不僅僅是協(xié)議，它還是一個(gè)Java對(duì)象，一個(gè)Jar包。
既然是Java對(duì)象，就意味著我們就有可能讓DTO承載除了getter，setter之外的更多職能。這個(gè)問(wèn)題以前沒(méi)有引起我的重視，但是最近在思考domain model的時(shí)候，我發(fā)現(xiàn)，我們是可以在讓二方庫(kù)承擔(dān)更多職責(zé)的，發(fā)揮更大的作用。
實(shí)際上，在阿里，我發(fā)現(xiàn)有些團(tuán)隊(duì)已經(jīng)在這么實(shí)踐了，而且我覺(jué)得效果還不錯(cuò)。比如，中臺(tái)的類目二方庫(kù)，在這個(gè)事情上就做了比較好的示范。類目是商品中比較復(fù)雜的邏輯，里面涉及很多計(jì)算，我們先看一下類目二方庫(kù)的代碼是怎么寫的：
從上面的代碼，我們可以發(fā)現(xiàn)這已經(jīng)遠(yuǎn)遠(yuǎn)超出DTO的范疇了，這就是一個(gè)Domain Model（有數(shù)據(jù)，有行為，有繼承）。這樣做合適嗎？我認(rèn)為是合適的：
- 首先，DefaultStdCategoryDO用到的所有數(shù)據(jù)都是自恰的，即這些計(jì)算是不需要借助外面的輔助，自己就能完成。比如判斷是否是根類目，是否是葉子類目，獲取類目的名稱路徑等，都是依靠自己就能完成。
- 其次，這就是一種共享內(nèi)核，我把自己領(lǐng)域的知識(shí)（語(yǔ)言、數(shù)據(jù)和行為）通過(guò)二方庫(kù)暴露出去了，假如有100個(gè)應(yīng)用需要使用isRoot( )做判斷，你們都不需要自己實(shí)現(xiàn)了。
什么？不是說(shuō)不推薦共享內(nèi)核的做法嗎？（好吧，小孩子才分對(duì)錯(cuò)，好嗎）。此處的共享內(nèi)核我認(rèn)為是有積極意義的，特別是類目這種輕數(shù)據(jù)、重計(jì)算的場(chǎng)景。不過(guò)，共享帶來(lái)的緊耦合也的確是一個(gè)問(wèn)題。所以如果我是類目服務(wù)的Consumer的話，我會(huì)選擇用一個(gè)Wrapper去對(duì)Category進(jìn)行包裝復(fù)用，這樣既可以復(fù)用它的領(lǐng)域能力，又可以起到隔離防腐的作用。
COLA中的二方庫(kù)
說(shuō)到這里，我想你應(yīng)該已經(jīng)理解我對(duì)二方庫(kù)的態(tài)度了。是的，二方庫(kù)不應(yīng)該僅僅是接口和DTO，而是領(lǐng)域的重要組成部分，是實(shí)現(xiàn)Shared Kernel的重要手段。
因此，我打算在COLA 2.0中擴(kuò)大二方庫(kù)的職責(zé)范圍。主要包括兩點(diǎn)：
注意，這只是建議，不是標(biāo)準(zhǔn)。實(shí)際上，我們永遠(yuǎn)要在共享和耦合之間做一個(gè)權(quán)衡，世界上沒(méi)有完美的架構(gòu)，也沒(méi)有完美的設(shè)計(jì)。 合不合適，還需要你自己根據(jù)實(shí)際場(chǎng)景自己去定奪。
COLA框架的擴(kuò)展機(jī)制
至此，關(guān)于COLA 2.0的改動(dòng)點(diǎn)我已經(jīng)交代的差不多了。再追加一個(gè)彩蛋吧。泄密一下COLA作為一個(gè)框架（Framework）是如何支持?jǐn)U展的。
框架作為一個(gè)組件是被集成在系統(tǒng)中完成某一特定任務(wù)的，比如logback作為一個(gè)日志框架是幫助我們解決打印日志、日志格式、日志存儲(chǔ)等問(wèn)題的。但面對(duì)各種應(yīng)用場(chǎng)景，框架本身沒(méi)辦法預(yù)測(cè)你想要的日志格式、日志歸檔的方式。這些地方需要一個(gè)擴(kuò)展機(jī)制，賦能用戶自己去配置、去擴(kuò)展。
就擴(kuò)展的實(shí)現(xiàn)方式而言，一般有兩種方式，一種是基于接口的擴(kuò)展，一種是基于數(shù)據(jù)配置的擴(kuò)展。
基于接口的擴(kuò)展
基于接口的擴(kuò)展，主要是利用面向?qū)ο蟮亩鄳B(tài)機(jī)制，先在框架中定義一個(gè)接口（或者抽象方法）和處理該接口的模板，然后用戶實(shí)現(xiàn)自己的定制。 其原理如下圖所示：
這種擴(kuò)展方式在框架中使用很廣泛，例如Spring中的ApplicationListener，用戶可以實(shí)現(xiàn)這個(gè)Listener來(lái)做容器初始化之后的特殊處理。再比如logback中的AppenderBase，用戶可以通過(guò)繼承AppenderBase實(shí)現(xiàn)定制的Appender訴求（往消息隊(duì)列發(fā)送日志）。
COLA作為一個(gè)框架，這樣的擴(kuò)展能力在所難免，比如，我們有一個(gè)ExceptionHandlerI，在框架中我們提供了一個(gè)默認(rèn)實(shí)現(xiàn)，代碼如下：
但是，并不是每個(gè)應(yīng)用都愿意這樣的安排，因此我們提供了擴(kuò)展，當(dāng)用戶提供了自己ExceptionHandlerI實(shí)現(xiàn)的時(shí)候，優(yōu)先使用用戶的實(shí)現(xiàn)，如果用戶沒(méi)有提供，使用默認(rèn)實(shí)現(xiàn)：
基于數(shù)據(jù)配置的擴(kuò)展
基于配置數(shù)據(jù)的擴(kuò)展，首先要約定一個(gè)數(shù)據(jù)格式，然后通過(guò)利用用戶提供的數(shù)據(jù)，組裝成實(shí)例對(duì)象，用戶提供的數(shù)據(jù)是對(duì)象中的屬性（有時(shí)候也可能是類，比如slfj中的StaticLoggerBinder），其原理如下圖所示：
我們一般在應(yīng)用中使用的KV配置都屬于這種形式，框架中的使用場(chǎng)景也很多，比如上面提到的logback中對(duì)日志格式、日志大小的logback.xml配置。
在COLA中，我們通過(guò)Annotation對(duì)擴(kuò)展點(diǎn)的配置@Extension(bizId = "tmall", useCase = "placeOrder", scenario = "88vip")，也是一種典型的基于數(shù)據(jù)的配置擴(kuò)展。
如何使用COLA 2.0
源代碼
COLA 2.0的源代碼在 https://github.com/alibaba/COLA
生成COLA應(yīng)用
COLA 2.0 提供了兩套Archetype，一套是純后端應(yīng)用，另一套是Web后端應(yīng)用，他們的區(qū)別是Web后端應(yīng)用比純后端應(yīng)用多了一個(gè)Controller模塊，其它都一樣。Archetype的二方庫(kù)我已經(jīng)上傳到Maven Repo了，可以通過(guò)如下命令生成COLA應(yīng)用：
生成純后端應(yīng)用（沒(méi)有Controller）
mvnarchetype:generate -DgroupId=com.alibaba.demo -DartifactId=demo -Dversion=1.0.0-SNAPSHOT-Dpackage=com.alibaba.demo-DarchetypeArtifactId=cola-framework-archetype-service-DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=2.1.0-SNAPSHOT生成Web后端應(yīng)用（有Controller）
mvn archetype:generate -DgroupId=com.alibaba.demo -DartifactId=demo-Dversion=1.0.0-SNAPSHOT -Dpackage=com.alibaba.demo-DarchetypeArtifactId=cola-framework-archetype-web-DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=2.1.0-SNAPSHOT我們假設(shè)新建的應(yīng)用叫demo，那么執(zhí)行命令后，會(huì)看到如下的模塊結(jié)構(gòu)，上部分是應(yīng)用骨架，下部分是COLA框架。
在生成的應(yīng)用里面有一些demo的代碼，可以直接用"mvn test"進(jìn)行測(cè)試。如果是Web后端應(yīng)用，可以運(yùn)行TestApplication啟動(dòng)Spring Boot容器，然后直接通過(guò)REST URL http://localhost:8080/customer?name=Alibaba 訪問(wèn)服務(wù)。
COLA 2.0整體架構(gòu)
最后，按照老規(guī)矩，還是給兩張全局的架構(gòu)視圖。以便你可以從全局上把握COLA。
注意：COLA有兩層含義，一層含義是作為框架的COLA，主要提供一些應(yīng)用中所需共用組件的支持。另一層含義是指COLA架構(gòu)，是指通過(guò)COLA Archetype生成的應(yīng)用骨架的架構(gòu)。這里所說(shuō)的架構(gòu)視圖是應(yīng)用架構(gòu)視圖。
依賴視圖
調(diào)用視圖
總結(jié)
以上是生活随笔為你收集整理的component是什么接口_阿里高级技术专家：整洁的应用架构“长”什么样？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： mysql 聚簇索引和非聚簇索引_图文并
- 下一篇： python的代码在哪写_python代