前幾天和幾個餓了么的同學聊天，一聽說他們還在用COLA 1.0，我二話沒說，90度鞠躬，賠禮道歉，虛心聆聽他們的吐槽，COLA的初衷旨在控制復雜度，救碼農于水火，慚愧的是，早期的思想不成熟，設計也多有缺陷，不僅沒幫到他們，反而坑了他們，實在抱歉，

實際上，我在COLA 3.0迭代的時候，已經舉起奧卡姆剃刀，砍掉了很多東西，

然而還不夠，主要體現在對架構的思考還不夠透徹，再三考量，我覺得有必要對COLA進行一次重新梳理，回歸初心，讓COLA真正成為應用架構的最佳實踐，幫助廣大的業務技術同學，脫離醬缸代碼的泥潭！

應用架構的本質

什么是架構？十個人可能有十個回答，架構在技術的語境下，就和架構師一樣魔幻，我曾經看過一本技術書，用了一章的篇幅討論架構的定義，最終也沒有說明白，

實際上，定義架構也沒那么難，如下圖所示，架構的本質，簡單來說，就是要素結構，所謂的要素（Components）是指架構中的主要元素，結構是指要素之間的相互關系（Relationship），

例如組織架構，其要素是什么？組成組織的要素當然是人，結構呢？結構是人與人之間的關系，因此，組織架構就是關于定義人的職責劃分，以及人與人之間協作關系的一種設計方法，

同樣，對于應用架構而言，代碼是其核心組成要素，結構就是這些代碼該如何被組織，也就是要如何處理模塊（Module）、組件（Component）、包（Package）和類（Class）之間的關系，簡而言之，應用架構就是要解決代碼要如何被組織的問題，

一個沒有架構的應用系統，就像一堆隨意堆放、雜亂無章的玩具，只有熵值，沒有熵減，而一個有良好架構的應用系統，有章法、有結構，一切都顯得緊緊有條，

好的組織架構會遵循一定的架構模式，大部分的組織都會按職能和業務來設計自己的架構，如果你反其道而行之，硬要把銷售、財務和技術人員放在一個部門，就會顯得很奇怪，

同樣，好的應用架構，也遵循一些共同模式，不管是六邊形架構、洋蔥圈架構、整潔架構、還是COLA架構，都提倡以業務為核心，解耦外部依賴，分離業務復雜度和技術復雜度，

應用架構的本質，就是要從繁雜的業務系統中提煉出共性，找到解決業務問題的最佳共同模式，為開發人員提供統一的認知，治理混亂，幫助應用系統“從混亂到有序”，COLA架構就是為此而生，其核心職責就是定義良好的應用結構，提供最佳實踐，

COLA 架構

自從COLA誕生以來，已經被使用在很多的業務系統里面，有CRM的業務，有電商的業務，有物流的業務，有外賣業務，有排課系統… COLA作為應用架構，有一定的普適性，是因為業務問題都有一定的共性，例如，典型的業務系統都需要：

• 接收request，回應response；
• 做業務邏輯處理，像校驗引數，狀態流轉，業務計算等等；
• 和外部系統有聯動，像資料庫，微服務，搜索引擎等；

正是有這樣的共性存在，才會有很多普適的架構思想出現，比如分層架構、六邊形架構、洋蔥圈架構、整潔架構（Clean Architecture）、DDD架構等等，

這些應用架構思想雖然很好，但我們很多同學還是“不講Co德，明白了很多道理，可還是過不好這一生”，問題就在于缺乏實踐和指導，COLA的意義就在于，他不僅是思想，還提供了可落地的實踐，應該是為數不多的應用架構層面的開源軟體，

分層結構

假如你是一個公司的CTO要管100號人，你怎么管？按照管理學的定義，一個人的管理幅度如果超過10個，管理就會變得很困難，因此，管100號人，你可以把他們分成10個小組，這樣你管理10個小組長就好了，

所有的復雜系統都會呈現出層級結構，管理如此，軟體設計也不例外，你能想象如果網路協議不是四層，而是一層，意味著，你要在應用層去處理鏈路層的bit資料流會是怎樣的情景嗎？同樣，應用系統處理復雜業務邏輯也應該是分層的，下層對上層屏蔽處理細節，每一層各司其職，分離關注點，而不是一個ServiceImpl解決所有問題，

對于一個典型的業務應用系統來說，COLA會做如下層次定義，每一層都有明確的職責定義：

1）適配層（Adapter Layer）：負責對前端展示（web，wireless，wap）的路由和適配，對于傳統B/S系統而言，adapter就相當于MVC中的controller；

2）應用層（Application Layer）：主要負責獲取輸入，組裝背景關系，引數校驗，呼叫領域層做業務處理，如果需要的話，發送訊息通知等，層次是開放的，應用層也可以繞過領域層，直接訪問基礎實施層；

3）領域層（Domain Layer）：主要是封裝了核心業務邏輯，并通過領域服務（Domain Service）和領域物件（Domain Entity）的方法對App層提供業務物體和業務邏輯計算，領域是應用的核心，不依賴任何其他層次；

4）基礎實施層（Infrastructure Layer）：主要負責技術細節問題的處理，比如資料庫的CRUD、搜索引擎、檔案系統、分布式服務的RPC等，此外，領域防腐的重任也落在這里，外部依賴需要通過gateway的轉義處理，才能被上面的App層和Domain層使用，

包結構

分層是屬于大粒度的職責劃分，太粗，我們有必要往下再down一層，細化到包結構的粒度，才能更好的指導我們的作業，

還是拿一堆玩具舉例子，分層類似于拿來了一個架子，分包類似于在每一層架子上又放置了多個收納盒，所謂的內聚，就是把功能類似的玩具放在一個盒子里，這樣可以讓應用結構清晰，極大的降低系統的認知成本和維護成本，

那么，對于一個后端應用來說，應該需要哪些收納盒呢？這一塊的設計真可謂是費了老鼻子勁了，基本上每一次COLA的迭代都會涉及到包結構的調整，迭代到現在，才算基本穩定下來，

各個包結構的簡要功能描述，如下表所示：

你可能會有疑問，為什么Domain的model是可選的？因為COLA是應用架構，不是DDD架構，在作業中，很多同學問我領域模型要怎么設計，我的回答通常是：無有必要勿增物體，領域模型對設計能力要求很高，沒把握用好，一個錯誤的抽象還不如不抽象，寧可不要用，也不要濫用，不要為了DDD而DDD，

問題的關鍵是要看，新增的模型沒有給你帶來收益，比如有沒有幫助系統解耦，有沒有提升業務語意表達能力的提升，有沒有提升系統的可維護性和可測性等等，

模型雖然可選，但DDD的思想是一定要去學習和貫徹的，特別是統一語言、邊界背景關系、防腐層的思想，值得深入學習，仔細體會，實際上，COLA里面的很多設計思想都來自于DDD，其中就包括領域包的設計，

前面的包定義，都是功能維度的定義，為了兼顧領域維度的內聚性，我們有必要對包結構進行一下微調，即頂層包結構應該是按照領域劃分，讓領域內聚，

也就是說，我們要綜合考慮功能和領域兩個維度包結構定義，按照領域和功能兩個維度分包策略，最后呈現出來的，是如下圖所示的頂層包節點是領域名稱，領域之下，再按功能劃分包結構，

例如，在我們剛剛上線的一個云店鋪（cloudstore）專案中，按照COLA的分包策略，我們在每一個module下面首先按照領域做一個頂層劃分，然后在領域內，再按照功能進行分包，

解耦

“高內聚，低耦合”這句話，你作業的越久，就越會覺得其有道理，

所謂耦合就是聯系的緊密程度，只要有依賴就會有耦合，不管是行程內的依賴，還是跨行程的RPC依賴，都會產生耦合，依賴不可消除，同樣，耦合也不可避免，我們所能做的不是消除耦合，而是把耦合降低到可以接受的程度，在軟體設計中，有大量的設計模式，設計原則都是為了解耦這一目的，

在DDD中有一個很棒的解耦設計思想——防腐層（Anti-Corruption），簡單說，就是應用不要直接依賴外域的資訊，要把外域的資訊轉換成自己領域背景關系（Context）的物體再去使用，從而實作本域和外部依賴的解耦，

在COLA中，我們把AC這個概念進行了泛化，將資料庫、搜索引擎等資料存盤都列為外部依賴的范疇，利用依賴倒置，統一使用gateway來實作業務領域和外部依賴的解耦，

其實作方式如下圖所示，主要是在Domain層定義Gateway介面，然后在Infrastructure提供Gateway介面的實作，

舉個例子，假如有一個電商系統，對于下單這個操作，它需要聯動訂單服務、商品服務、庫存服務、營銷服務等多個系統才能完成，

那么在訂單域，該如何獲取商品和庫存資訊呢？最直接的方式，無外乎就是RPC呼叫商品和庫存服務，拿到DTO直接使用就完了，

然而，商品域吐出的是一個大而全的DTO（可能包含幾十個欄位），而在下單這個階段，訂單所需要的可能只是其中幾個欄位而已，更合適的做法，應該是在訂單域中，使用gateway對商品域和庫存域的依賴進行解耦，

這樣做有兩個好處，一個是降低了對外域資訊依賴的耦合；另一個是通過背景關系映射（Context mapping），確保本領域邊界背景關系（Bounded context）下領域知識的完整性，實作了統一語言（Ubiquitous language），

COLA Archetype

以上就是COLA架構的核心內容了，然而這么多module，這么多package，如果要手動去創建的話，是非常繁瑣和費時的，為了能夠快速創建滿足COLA架構的應用，我創建了兩個Maven Archetype，

1. 一個是用來創建純后端服務的archetype：cola-archetype-service，
2. 一個是用來創建adapter和后端服務一體的web應用archetype：cola-archetype-web，

另外，你也可以使用阿里云的應用生成器去生成一個COLA應用，只是那邊的版本沒有同步更新，可能會老舊一點，

COLA組件

使用過老版本COLA的同學，應該知道，COLA除了架構之外，還提供了一些框架級別的功能，比如攔截器功能，擴展點功能等，

之前，這種框架功能和架構混淆在一起，會讓人以為使用COLA，就必須要使用這些功能，實際上二者是可以分開使用的，也就是說，你可以單純的使用COLA架構，而不使用任何COLA組件提供的功能也是完全沒問題的，

當然，我還是強烈推薦你可以有選擇的使用這些COLA組件，畢竟這些組件都是我們在實際作業中的總結沉淀，其復用性和價值是被反復驗證過的，

為了方便管理，以及更清晰的把架構和框架區分開來，在此次COLA 4.0的升級中，我把這些功能組件全部收攏到了cola-components下面，到目前為止，我們已經沉淀了以下組件：

這些組件是一個良好的開端，我相信，在未來會有更多有用的組件加入，當然，作為一個開源專案，如果你有好的組件idea，歡迎你隨時為這個組件庫添磚加瓦，

COLA 4.0

總結一下，在本次COLA升級中，我們進一步明確了架構和框架功能的定義，升級之后，如下圖所示，COLA會被分成COLA架構和COLA組件兩個部分：

1. COLA架構：關注應用架構的定義和構建，提升應用質量，
2. COLA組件：提供應用開發所需要的可復用組件，提升研發效率，

COLA 開源地址： https://github.com/alibaba/COLA

你可以按照以下步驟去使用COLA：

** 第一步：安裝 cola archetype **
下載cola-archetypes下的原始碼到本地，然后本地運行mvn install安裝，

** 第二步：安裝 cola components **
下載cola-components下的原始碼到本地，然后本地運行mvn install安裝，

** 第三步：創建應用 **
執行以下命令：

mvn archetype:generate  -DgroupId=com.alibaba.demo -DartifactId=demoWeb -Dversion=1.0.0-SNAPSHOT -Dpackage=com.alibaba.demo -DarchetypeArtifactId=cola-framework-archetype-web -DarchetypeGroupId=com.alibaba.cola -DarchetypeVersion=4.0.0

命令執行成功的話，會看到如下的應用代碼結構：

** 第四步：運行應用 **
首先在demoWeb目錄下運行mvn install（如果不想運行測驗，可以加上-DskipTests引數），然后進入start目錄，執行mvn spring-boot:run，
運行成功的話，可以看到SpringBoot啟動成功的界面，

生成的應用中，已經實作了一個簡單的Rest請求，可以在瀏覽器中輸入 http://localhost:8080/helloworld 進行測驗，