從分層架構到六邊形架構
在計算機領域很多概念都是抽象的，為了能夠清晰地劃分這些抽象的復雜概念，隨處可見各種分層式的設計方式。比如計算網(wǎng)路的七層通信協(xié)議雾鬼，把復雜的網(wǎng)絡通信劃分成更容易管理的層，明確定義各層的職責范圍宴树，各層都可以采用最合適的技術來實現(xiàn)策菜。當任何一層發(fā)生變化時，只要層間接口關系保持不變酒贬，則在這層以上或以下各層均不受影響又憨。
在常見的軟件系統(tǒng)的架構中也有一種4層架構設計，通常從前到后會劃成：用戶接口層锭吨，應用層蠢莺，領域層，基礎設施層耐齐。
- 用戶接口層只需要關注如何同使用者打交道浪秘，不需要關注核心的業(yè)務邏輯蒋情，例如把用戶提交的數(shù)據(jù)經(jīng)過轉碼處理后提供給應用層埠况。
- 應用層的關注點是如何組裝核心的領域層來提供復雜的組合服務，例如應用層可以從領域層的用戶倉庫獲取用戶信息棵癣，從領域層的訂單倉庫獲取訂單信息辕翰，然后在應用層把用戶信息和訂單信息組裝在一起返回給用戶接口層
- 領域層處理的業(yè)務問題，是更加內(nèi)聚的領域業(yè)務狈谊，不同業(yè)務之間要做到低耦合喜命。例如在用戶聚合中就只處理用戶相關的邏輯，不應該包含訂單河劝，支付這些其它的業(yè)務邏輯壁榕。
- 基礎設施層是不包含任何業(yè)務邏輯的底層支持，例如生成pdf或者excel赎瞎，或者把數(shù)據(jù)持久化到數(shù)據(jù)庫的ORM框架
但是這樣的分層架構會導致其他三層尤其是領域層對基礎設施層產(chǎn)生依賴牌里。這種依賴會導致當基礎設施層發(fā)生變更的時候，會導致其它三層也要跟隨變動务甥，這是我們不希望放生的事情牡辽，尤其是涉及核心業(yè)務邏輯的領域層，我們不希望因為某種生成excel或者pdf的技術發(fā)生變化而要修改領域層敞临。
那么如果考慮對基礎設施進行解耦的方法态辛，可供選擇的的方式有依賴倒置，在每一層定義對應的技術接口挺尿，然后在基礎設施層實現(xiàn)這個接口奏黑，再通過一些依賴注入框架在運行式把實現(xiàn)注入進來炊邦，這樣就把原來其它三層依賴基礎設施層的情況倒置成了基礎設施層依賴其它三層了。
有趣的是攀涵，當我們在分層架構中采用依賴倒置原則時铣耘，我們會發(fā)現(xiàn)事實上已經(jīng)不存在分層的概念了。無論高層還是低層以故，都只依賴于抽象的接口蜗细。如果我們這時把分層架構推平，這就是在微服務領域非常著名的六邊形架構怒详。
六邊形架構是Alistair Cockburn提出的炉媒，其實是把原來的分層架構轉換了一下視角，從原來的上下結構變成了內(nèi)外結構昆烁。六邊形架構把原來一個系統(tǒng)的輸入和輸出都統(tǒng)一來處理吊骤，輸入輸出對接的都是外部系統(tǒng)，都需要一個適配器來進行轉換静尼。所以不論是處理輸入的HTTP請求白粉，還是處理輸出的數(shù)據(jù)庫存儲都應該有一個適配器來負責接入。適配器會調用負責業(yè)務邏輯組合的應用層鼠渺，而應用層負責調用核心的領域層鸭巴。
相比于應用層，領域層通常更少變化拦盹。在這樣的架構關系下鹃祖，當需要修改一個負責連接數(shù)據(jù)庫的ORM工具時，或者是應用層返回的訂單信息需要增加物流狀態(tài)時普舆，都不需要去修改最核心的領域層恬口。
為什么是六邊形
不知道大家在看到六邊形架構這個名字的時候會不會產(chǎn)生一個疑問，就說是為什么是六邊形沼侣，不是七邊形祖能，五邊形。
這個問題其實困擾了我蠻久蛾洛，但是當我在鄭也夫老師的社會學專題50講里面找到了答案养铸。六邊形這個概念源自于城市規(guī)劃，有兩個德國人雅潭，一個是克里斯塔勒揭厚，他的研究興趣是人口密度和商品銷售關系。他1933年寫出一部書扶供，叫做《德國南部中心地原理》筛圆。另外一個是廖什 ，他的興趣在于研究空間秩序椿浓，他在1940年寫出一部書叫做《經(jīng)濟空間秩序》太援。
這兩個人各自獨立的提出了六邊形理論：
每個商家銷售的范圍是一個圓闽晦。因為人們買東西有交通成本，所以導致著以一個賣點為中心提岔，銷售范圍是圍繞著這個中心畫的一個圓仙蛉。當人口越來越多的時候，商家也就越來越多碱蒙，那個圓形越來越多荠瘪，導致著一個圓形跟另一個圓形相互擠壓，最后壓成了一個蜂巢一樣的緊密相連的正六邊形的組合體赛惩。
最低級的銷售點是集市哀墓，銷售一些最通常的日用品，構成了最小的六邊形拼湊出來的平面喷兼。稍大一點的城市會賣衣服篮绰、鞋等等中檔的東西，它們就是中型的六邊形季惯。大的都市會賣一些很高檔的東西吠各，珠寶、珍貴的皮毛等等勉抓。這些大的正六邊形拼湊出一個大的平面贾漏。并且在一個廣大的地域中，大都市銷售區(qū)是大六邊形的對接琳状，其中包含著中小六邊形磕瓷。
除了人類的集市盒齿，還有一種自然界的天然六邊形就是蜂巢念逞。但是你有想過這個問題嗎，蜜蜂在搭建蜂巢的時候又沒有測量工具边翁，它們是怎么搭建出來比例那么標準的的六邊形蜂巢的呢翎承。
其實蜜蜂根本就不曾想過要搭建六邊形，蜜蜂在搭建蜂巢的時候是按照記得身體的大小圍出了圓形的一個個蜂巢符匾，請看下圖：
然后這一個個小圓經(jīng)過蜂巢自己本身的拉伸和風化叨咖，就變成了六邊形。蜜蜂本來就是要造圓形巢的啊胶，但是由于自然界本身的趨于穩(wěn)定的焓變規(guī)則甸各，軟的圓形巢就拉成六邊形了。
[圖片上傳失敗...(image-750f2e-1541523534115)]
那么為什么圓形會被拉伸成六邊形呢焰坪？阿爾法小分隊有一個視頻專門介紹了這個問題的數(shù)學原理（視頻傳送門）趣倾。在視頻中用小時候經(jīng)常玩的泡泡做了一個簡單的實驗，當四個泡泡湊仔一起的的時候某饰，在泡泡邊界上出現(xiàn)的所有夾角都是120度儒恋。所以當很多個泡泡擠在一起的時候善绎，由于在拉扯力的作用下邊界夾角都是120度，所以一個個泡泡就“天然的”變成了六邊形诫尽。而蜂巢禀酱，人類集市是遵循這個自然規(guī)律。
回到微服務架構牧嫉，雖然“六邊形架構”這個概念是Alistair Cockburn創(chuàng)造出來的剂跟，但是由于六邊形代表了自然規(guī)律，所以我認為六邊形架構是“純天然”的酣藻。而且如果我們把創(chuàng)建的微服務看成一個個小泡泡浩聋，那么把這些小泡泡排列在一起以后，自然法則會讓他們變成一個個六邊形臊恋。而不可能是五變形或者七邊形衣洁。
介紹完了六邊形的故事，讓我們進入六邊形架構的微服務內(nèi)部抖仅，看看里面的代碼是什么樣子的坊夫。
一個六邊形架構的代碼結構示例
首先在一個微服務的根目錄上應該只有3個包，adapter撤卢，application和domain环凿。而且還要嚴格限制依賴關系：
- domain中不可以依賴任何application和adapter中的代碼
- application中不可以依賴任何adapter中的代碼
假設一個簡單的場景：用戶從界面提交一個支付請求，最終這個支付請求的相關信息會被存入數(shù)據(jù)庫中放吩。
接受請求這段很好實現(xiàn)智听，在adapter層里有一個controller來處理請求，把請轉換成領域模型payment渡紫，然后調用application層SubmitPaymentApplication的submit方法來提交payment到推。然后SubmitPaymentApplication會調用domain層的PaymentRepository. 這時候會有一個麻煩的問題，通常來說Repository里面都會依賴具體的ORM工具惕澎，比如hibernate或者Mybatis莉测。但是前面說過我們希望Domain層是不要有任何外部依賴的，所以解決這個問題的方法就是在只在domain層定義PaymentRepository的接口唧喉，然后在Adapter層使用ORM工具實現(xiàn)這個接口捣卤。
ORM工具是在面向對象程序中進行數(shù)據(jù)庫持久化的好用工具，而且現(xiàn)在流行的ORM工具都提供了從數(shù)據(jù)庫表到實體類的自動生成功能八孝，讓開發(fā)者盡可能的減少機械化的工作董朝。但是這些好用的工具帶來的一個問題就是實體越來越貧血，實體里面只是有一堆屬性和對應的get/set方法而已干跛。但是在六邊形架構里面子姜，由于domain層的實體不需要由ORM生成，數(shù)據(jù)庫持久化相關的工作都在外面的adapter層中完成驯鳖，所以開發(fā)者就可以放心的在domain中使用枚舉等各種編程語言的特性闲询，還可以在實體中放心的實現(xiàn)各種本來就屬于實體的行為久免。
思辨小結
這幾年由于微服務的原因六邊形架構也變得熱了起來。但是要真的用好六邊形架構扭弧，我們需要對這個概念有一個更深入的理解：知道它是怎么提出來的阎姥？它解決的是什么問題？為什么是六條邊鸽捻？弄清楚了這些呼巴，在應用六邊形架構的時候才能清楚地知道什么邏輯只能屬于哪一層，哪一層不能依賴哪一層御蒲。堅持這些原則的價值是：當有新需求或者需求發(fā)生變更時衣赶，重用代碼和修改代碼都是讓人愉悅的事情。
把使用ORM的數(shù)據(jù)庫持久化實現(xiàn)放在adapter的一個可能問題是厚满，由于domain層的實體更貼近業(yè)務府瞄，所以這些實體模型無法直接給ORM使用，這就需要在adapter里面再實現(xiàn)一套專門對應數(shù)據(jù)庫表的對象模型出來碘箍，并在adapter里面吧domain的實體轉換成這些模型再進行數(shù)據(jù)庫操作遵馆。這樣看起來好像會有兩套冗余的業(yè)務模型，一個在domain中丰榴，一個在adapter里面货邓。但其實只有domain中的才是真正的業(yè)務模型，adapter里面的模型只是數(shù)據(jù)庫表的一個映射對象而已四濒。這種方式很好地把領域模型和持久化相關實現(xiàn)進行了解耦换况，我們可以完全拋開數(shù)據(jù)庫或者ORM的技術限制，去設計能夠真正和業(yè)務對應的領域模型盗蟆。
