二、六邊形架構(gòu)

六邊形架構(gòu)又稱“端口與適配器”河闰，六邊形每條不同的邊代表了不同種類的端口科平，端口要么處理輸入，要么處理輸出姜性。如下圖所示：適配器A和B是一個(gè)邊瞪慧，適配器C和D是另一個(gè)邊，這里有可能就是適配器A和適配器B接收到的是輸入端發(fā)來(lái)的HTTP請(qǐng)求部念，適配器C和適配器D是輸入端發(fā)來(lái)的TCP請(qǐng)求弃酌。

不過(guò)針對(duì)六邊形架構(gòu)中的端口，并沒(méi)有明確的定義儡炼，它是一個(gè)非常靈活的概念妓湘。無(wú)論采用哪種方式對(duì)端口進(jìn)行劃分，當(dāng)客戶請(qǐng)求到達(dá)時(shí)乌询，都應(yīng)該有相應(yīng)的適配器對(duì)輸入進(jìn)行轉(zhuǎn)化榜贴，然后端口將調(diào)用應(yīng)用程序的某個(gè)操作或者向應(yīng)用程序發(fā)送一個(gè)事件，控制權(quán)由此交給內(nèi)部區(qū)域妹田。

以下就是請(qǐng)求到達(dá)HTTP的輸入端口時(shí)唬党，相應(yīng)的適配器將對(duì)請(qǐng)求的處理委派給應(yīng)用服務(wù)——OrderService。

我們?cè)倏瓷蠄D六邊形架構(gòu)中的適配器E鬼佣、F驶拱、G，我們可以通過(guò)不同的方式實(shí)現(xiàn)資源庫(kù)沮趣，比如：關(guān)系型數(shù)據(jù)庫(kù)屯烦、基于文檔的存儲(chǔ)、基于分布式緩存和內(nèi)存存儲(chǔ)等房铭。如果應(yīng)用程序向外界發(fā)送領(lǐng)域事件消息驻龟，我們將使用適配器H進(jìn)行處理。由于適配器H是處理消息輸出的缸匪，我們可以將其使用不同的端口翁狐。

由于六邊形架構(gòu)采用了輸入/輸出適配器，所以凌蔬，可以很輕易的開(kāi)發(fā)用于測(cè)試的輸入適配器和輸出適配器露懒。那么闯冷，在整個(gè)應(yīng)用程序和領(lǐng)域模型就可以在沒(méi)有客戶和存儲(chǔ)機(jī)制的條件下進(jìn)行設(shè)計(jì)和開(kāi)發(fā)。這樣懈词，在開(kāi)發(fā)過(guò)程中蛇耀，我們就可以在核心領(lǐng)域上進(jìn)行持續(xù)開(kāi)發(fā)，而不需要考慮那些支撐性的技術(shù)組件坎弯。

如果你采用的是嚴(yán)格分層架構(gòu)纺涤，那么你應(yīng)該考慮推平這種架構(gòu)，然后開(kāi)始采用端口與適配器抠忘。通過(guò)合理的適配器設(shè)計(jì)撩炊，我們可以保障內(nèi)部六邊形（應(yīng)用程序&領(lǐng)域模型）是不會(huì)泄漏到外部區(qū)域的，這樣也有助于形成一種清晰的應(yīng)用程序邊界崎脉。

六邊形架構(gòu)可以支持系統(tǒng)中的其他架構(gòu)拧咳，如：SOA、REST囚灼、事件驅(qū)動(dòng)骆膝、CQRS、數(shù)據(jù)網(wǎng)織啦撮、基于網(wǎng)格的分布式緩存谭网、Map-Reduce……六邊形架構(gòu)為這些架構(gòu)提供了堅(jiān)實(shí)的支撐基礎(chǔ)。

三赃春、REST

對(duì)于REST來(lái)說(shuō)，它其實(shí)是一種基于Web架構(gòu)的架構(gòu)風(fēng)格劫乱。這時(shí)候會(huì)有同學(xué)說(shuō)织中，我使用HTTP對(duì)服務(wù)請(qǐng)求的時(shí)候，也沒(méi)有采用什么所謂的REST架構(gòu)風(fēng)格衷戈，在項(xiàng)目使用中也沒(méi)出現(xiàn)什么大問(wèn)題跋梁稹？那為什么需要REST呢殖妇？其實(shí)刁笙，我相信這也絕對(duì)不是少數(shù)人會(huì)有疑問(wèn)，其實(shí)我們將REST稱之為“基于Web架構(gòu)的架構(gòu)風(fēng)格”谦趣，本質(zhì)是提供一種使用Web協(xié)議的更合理的方式疲吸。這就類似于當(dāng)我們?cè)贛ySQL中建表的時(shí)候，我們可以遵循數(shù)據(jù)庫(kù)三范式的方式去創(chuàng)建業(yè)務(wù)表前鹅，添加主鍵摘悴、外鍵、索引舰绘、復(fù)合索引蹂喻、非空約束葱椭、視圖、觸發(fā)器……口四，也可以像使用NoSQL一樣孵运，只創(chuàng)建兩個(gè)列，一個(gè)列作為Key蔓彩，用于存儲(chǔ)業(yè)務(wù)數(shù)據(jù)的唯一標(biāo)識(shí)掐松；另一個(gè)列作為Value，用于存儲(chǔ)序列化后的對(duì)象信息粪小。這兩種方式我們其實(shí)都是在使用MySQL數(shù)據(jù)庫(kù)大磺，區(qū)別就在于是否合理、是否可以使用到數(shù)據(jù)庫(kù)給我們提供的各種功能探膊。

同樣的道理杠愧，當(dāng)我們使用HTTP對(duì)服務(wù)的進(jìn)行請(qǐng)求的時(shí)候，如果遵循了REST風(fēng)格的架構(gòu)風(fēng)格逞壁，便可以獲得由于使用了REST風(fēng)格的HTTP所帶來(lái)的好處流济。那么具體來(lái)說(shuō)，使用還是不使用這種架構(gòu)風(fēng)格腌闯，還是與項(xiàng)目實(shí)際情況來(lái)確定的绳瘟。例如，我只是希望通過(guò)HTTP的方式觸發(fā)一個(gè)補(bǔ)償機(jī)制姿骏，那么糖声，即使不采用REST，也無(wú)所謂分瘦。

HTTP基于服務(wù)端而言蘸泻，是一種可以將服務(wù)資源對(duì)外暴露的重要方式之一，比如：我們想要獲取客戶的詳細(xì)信息嘲玫，那么客戶服務(wù)負(fù)責(zé)對(duì)客戶資源的管理悦施，所以，由客戶服務(wù)提供一個(gè)URI去团，將客戶信息以XML抡诞、JSON、HTML或者二進(jìn)制數(shù)據(jù)返回給客戶端土陪。

那么昼汗，既然我們可以通過(guò)HTTP的方式去獲取和操作資源，那么如果我們將資源也看做是一種對(duì)象旺坠，那么也會(huì)有對(duì)資源的增刪改查等操作乔遮。所以，當(dāng)我們引入RESTful時(shí)取刃，就可以通過(guò)HTTP中請(qǐng)求method的一些動(dòng)詞——GET蹋肮、PUT出刷、POST、DELETE坯辩，來(lái)對(duì)資源進(jìn)行不同行為的操作馁龟。Rest風(fēng)格支持（使用HTTP請(qǐng)求方式動(dòng)詞來(lái)表示對(duì)資源的操作）

雖然剛剛我們將資源類比為了一種對(duì)象漆魔，但是坷檩，究其本質(zhì)資源并不表示任何可以持久化的實(shí)體，它更像是封裝了某種行為改抡，當(dāng)我們將HTTP動(dòng)詞應(yīng)用在這些資源上時(shí)矢炼，我們實(shí)際上是在調(diào)用這些行為——處理某些業(yè)務(wù)邏輯、對(duì)其他系統(tǒng)發(fā)起領(lǐng)域事件阿纤、緩存某些數(shù)據(jù)句灌，獲取業(yè)務(wù)數(shù)據(jù)……

這里我們需要注意的是管引，當(dāng)我們暴露資源的時(shí)候携取，并不是要將領(lǐng)域模型直接暴露給外界违柏，因?yàn)檫@樣當(dāng)我們修改領(lǐng)域模型時(shí)候址，就會(huì)影響到暴露出來(lái)的接口。所以病涨，我們需要將客戶請(qǐng)求和響應(yīng)對(duì)象與領(lǐng)域模型隔離開(kāi)居夹，例如：客戶請(qǐng)求對(duì)象我們采用XxxVo幔烛、XxxQry和XxxCmd來(lái)進(jìn)行命名荆忍，領(lǐng)域模型內(nèi)的對(duì)象我們采用XxxDTO格带、XxxEntity來(lái)命名。通過(guò)使用不同的對(duì)象來(lái)起到表現(xiàn)層與應(yīng)用層/領(lǐng)域?qū)拥母綦x东揣。

四践惑、CQRS

CQRS（Cammand-Query Responsibility Segregation）：將查詢操作與命令操作進(jìn)行分離。其架構(gòu)圖如下圖所示：

在CQRS模式中嘶卧，一個(gè)方法要么是執(zhí)行某種動(dòng)作的命令（Cammand），要么是返回?cái)?shù)據(jù)的查詢（Query）凉袱，而不能兩者皆是芥吟。

• 如果一個(gè)方法修改了對(duì)象的狀態(tài)，該方法便是一個(gè)命令（Command）专甩，它不應(yīng)該返回?cái)?shù)據(jù)钟鸵。
• 如果一個(gè)方法返回了數(shù)據(jù)，該方法便是一個(gè)查詢（Query）涤躲，此時(shí)它不應(yīng)該通過(guò)直接的或間接的手段修改對(duì)象的狀態(tài)棺耍。

在以往我們涉及到的開(kāi)發(fā)模型中，同時(shí)包含著命令和查詢的聚合种樱。那么蒙袍，在CQRS中俊卤，我們會(huì)考慮將那些純粹的查詢功能從命令功能中分離出來(lái)。聚合將不再有查詢方法害幅，而是只有命令方法消恍。資源庫(kù)只提供新增（save()/add()）、更新（edit()/modify()/update()）以现、刪除（delete()/remove()）方法狠怨。針對(duì)于查詢方法，只提供根據(jù)唯一標(biāo)識(shí)來(lái)進(jìn)行查詢的方法（findUserById()/findUserByUserId()）邑遏。

有的同學(xué)會(huì)有疑問(wèn)佣赖，這么把命令和查詢拆分開(kāi)來(lái)，分別的構(gòu)建记盒，不是為系統(tǒng)增加了復(fù)雜度嘛憎蛤？但無(wú)論如何，不要急于否定這種架構(gòu)孽鸡。其實(shí)蹂午，我們需要記住一點(diǎn)，就是CQRS旨在解決數(shù)據(jù)顯示復(fù)雜性問(wèn)題彬碱。只有當(dāng)有這方面業(yè)務(wù)需求的時(shí)候豆胸，我們才會(huì)選擇這種架構(gòu)，而并非所有架構(gòu)都要按照CQRS的方式去構(gòu)建巷疼。

由于在上面的介紹中晚胡，我們已經(jīng)將查詢功能拆分出來(lái)了。那么下面我們就將原有的領(lǐng)域模型一分為二嚼沿，即：命令模型 & 查詢模型估盘。那么，對(duì)于命令操作骡尽，可以通過(guò)單獨(dú)的路徑抵達(dá)命令模型遣妥。而查詢操作，則請(qǐng)求到查詢處理器中攀细，并且可以采用不同的數(shù)據(jù)源箫踩，并且便于對(duì)查詢數(shù)據(jù)進(jìn)行優(yōu)化而不會(huì)影響到命令模型。

4.1> 查詢模型

對(duì)于查詢模型返回給客戶端的結(jié)果谭贪，一般來(lái)說(shuō)有兩種處理方式境钟，無(wú)論采用哪種方式，沒(méi)有絕對(duì)的好壞俭识，根據(jù)具體情況而定慨削。

方式一：直接返回查詢后的結(jié)果集或者基本的序列化數(shù)據(jù)（JSON/XML）。
方式二：返回封裝好的DTO或者VO對(duì)象。

針對(duì)于查詢模型缚态，它并不反映領(lǐng)域行為磁椒，只是用于數(shù)據(jù)顯示或生成數(shù)據(jù)報(bào)告。

在查詢模型中猿规，如果采用的是關(guān)系型數(shù)據(jù)庫(kù)衷快，那么視圖就代表著數(shù)據(jù)庫(kù)中的一張表。為了滿足不同的查詢需求姨俩，我們可以針對(duì)一個(gè)或多個(gè)視圖進(jìn)行組合拼裝蘸拔、數(shù)據(jù)過(guò)濾。

4.2> 命令處理器

客戶端提交的命令將被命令處理器接收环葵。一般來(lái)說(shuō)调窍，我們會(huì)采用如下兩種風(fēng)格去實(shí)現(xiàn)：

分類風(fēng)格：多個(gè)命令處理器位于同一個(gè)應(yīng)用服務(wù)中。我們可以根據(jù)不同的命令類型來(lái)尋找對(duì)應(yīng)的命令處理器张遭。優(yōu)點(diǎn)：簡(jiǎn)單邓萨，便于維護(hù)。
專屬風(fēng)格：每種命令處理器對(duì)應(yīng)一個(gè)處理類菊卷，這個(gè)類只提供一個(gè)用于處理某個(gè)指令的方法缔恳。優(yōu)點(diǎn)：每個(gè)處理類職責(zé)單一，處理器之間互相獨(dú)立洁闰。

在調(diào)用命令處理器的方式上歉甚，也可以分為兩種：

同步調(diào)用：提升整個(gè)流程的處理時(shí)間∑嗣迹可以在同一個(gè)事務(wù)下保證數(shù)據(jù)的一致性纸泄。
異步調(diào)用：可以實(shí)現(xiàn)與命令處理器的解耦，但是腰素，只有在有伸縮性需求的情況下才考慮采取異步方式聘裁。

但是，無(wú)論采取哪種風(fēng)格以及哪種調(diào)用方式弓千，一個(gè)處理器不能依賴于另一個(gè)處理器衡便。這樣可以保證對(duì)于任何處理器的重新部署都不會(huì)影響到其他處理器。

命令處理器通常只完成有限的功能洋访。例如砰诵，我們要通過(guò)某個(gè)命令處理器執(zhí)行某種命令，那么捌显，命令處理器將從資源庫(kù)中獲取聚合實(shí)例，然后再調(diào)用該聚合實(shí)例的某個(gè)行為方法总寒。如下所示：

@Transactional
public void orderToPay(String orderId, String paymentId) {
    Order order = orderRepository.orderOfId(orderId);
    Payment payment = paymentRepository.paymentOfId(paymentId);
    order.pay(payment);
}

4.3> 命令模型執(zhí)行業(yè)務(wù)行為

命令模型上每個(gè)方法在執(zhí)行完成時(shí)都將發(fā)布領(lǐng)域事件扶歪。下面我們以Order.pay(...)為例：

public class Order extends ConcurrencySafeEntity {
    ...
    public void pay(Payment payment) {
        ...
        // 發(fā)布領(lǐng)域事件
        DomainEventPublisher.instance().publish(new OrderPaid(this.orderId, payment.paymentId));
    }
    ...
}

當(dāng)我們對(duì)命令模型執(zhí)行更新操作后，需要通過(guò)發(fā)布領(lǐng)域事件，來(lái)通知查詢模型也執(zhí)行相應(yīng)的更新操作善镰。該領(lǐng)域事件的發(fā)布妹萨，是基于請(qǐng)求合法的情況下，并且針對(duì)查詢模型接收領(lǐng)域事件炫欺，需要添加冪等的能力乎完，否則因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者服務(wù)異常會(huì)導(dǎo)致多次相同事件觸發(fā)通知。請(qǐng)見(jiàn)下圖紅框所示：

對(duì)查詢模型的更新應(yīng)該是同步的呢品洛，還是異步的树姨？這取決于系統(tǒng)的負(fù)荷，也有可能取決于查詢模型數(shù)據(jù)庫(kù)的存儲(chǔ)位置桥状。數(shù)據(jù)的一致性約束和性能需求等因素對(duì)此也有很大的影響作用帽揪。如果要同步更新查詢模型，查詢模型和命令模型通常需要共享一個(gè)數(shù)據(jù)庫(kù)辅斟，這時(shí)我們會(huì)在同一個(gè)事務(wù)過(guò)程中處理更新转晰。這種方式可以保證兩種模型的數(shù)據(jù)達(dá)到完全一致性。

如果命令模型和查詢模型采取異步更新士飒，那么最終一致性問(wèn)題就擺在了我們的面前查邢。會(huì)出現(xiàn)命令已經(jīng)執(zhí)行成功，但是用戶查詢時(shí)酵幕，發(fā)現(xiàn)查詢模型中還是“舊”的數(shù)據(jù)扰藕。針對(duì)這個(gè)問(wèn)題，我們可以采取先將更新數(shù)據(jù)放入緩存中裙盾，用戶讀取數(shù)據(jù)的時(shí)候实胸，先查詢緩存，如果不存在番官，再去查詢模型的數(shù)據(jù)庫(kù)中獲取庐完。對(duì)于緩存數(shù)據(jù)，我們?cè)O(shè)定一個(gè)合理的過(guò)期時(shí)間徘熔。但是這種方式门躯，也沒(méi)法真正的解決這個(gè)問(wèn)題，并且隨著引入緩存中間件酷师，也對(duì)系統(tǒng)的穩(wěn)定性產(chǎn)生了影響讶凉。其次，我們可以采取業(yè)務(wù)數(shù)據(jù) + 創(chuàng)建日期的方式山孔，即：在展示數(shù)據(jù)后面懂讯，增加當(dāng)前所展示的數(shù)據(jù)的創(chuàng)建時(shí)間。這樣台颠，用戶可以根據(jù)數(shù)據(jù)創(chuàng)建時(shí)間褐望，來(lái)知道這個(gè)數(shù)據(jù)是新數(shù)據(jù)還是舊數(shù)據(jù)。當(dāng)然，還有其他多種的處理方式瘫里，具體選擇哪種方式实蔽，我們還是需要根據(jù)具體的業(yè)務(wù)場(chǎng)景來(lái)決定。

五谨读、事件驅(qū)動(dòng)架構(gòu)

5.1> 概述

事件驅(qū)動(dòng)架構(gòu)（Event-Driven Architecture局装，EDA）是一種用于處理事件的生成、發(fā)現(xiàn)和處理等任務(wù)的軟件架構(gòu)劳殖。

一個(gè)系統(tǒng)的輸出端口所發(fā)出的領(lǐng)域事件將被發(fā)送到另一個(gè)系統(tǒng)的輸入端口铐尚，此后輸入端口的事件訂閱方將對(duì)事件進(jìn)行處理。往往這種領(lǐng)域事件都是基于MQ的方式實(shí)現(xiàn)的闷尿。它除了在功能上實(shí)現(xiàn)了一步的事件傳輸之外塑径，也可以實(shí)現(xiàn)類似Linux中管道和過(guò)濾器的方式，即：cat log_history.log | grep orderId=123456 | wc -l

利用領(lǐng)域事件填具，我們可以采用如下方式實(shí)現(xiàn)：

上面的例子统舀，只是使用領(lǐng)域事件來(lái)類比Linux中的管道概念，在真實(shí)的企業(yè)應(yīng)用里劳景，我們將通過(guò)這種模式將一個(gè)大問(wèn)題分解成若干個(gè)較小的步驟來(lái)完成誉简，這使得分布式處理更容易理解和管理。

在DDD應(yīng)用場(chǎng)景中盟广，領(lǐng)域事件的名字將反映業(yè)務(wù)操作闷串。

5.2> 長(zhǎng)時(shí)處理過(guò)程——Saga

長(zhǎng)時(shí)處理過(guò)程（Long-Running Process）也稱為Saga，它是一種事件驅(qū)動(dòng)的筋量、分布式的并行處理模式烹吵。

我們對(duì)上面介紹的領(lǐng)域事件例子進(jìn)行改造，由LogInfoExecutive負(fù)責(zé)啟動(dòng)桨武，并且添加了新的過(guò)濾器ExceptionLogInfoCounter肋拔，用于統(tǒng)計(jì)所有發(fā)生了Exception異常的日志數(shù)，大家注意呀酸，此時(shí)它與LogInfoFinder是平行處理的凉蜂，那么整個(gè)長(zhǎng)時(shí)處理是否完成，就取決于統(tǒng)計(jì)指定查詢?nèi)罩拘畔⒌娜罩緮?shù)和統(tǒng)計(jì)所有發(fā)生了Exception異常的日志數(shù)是否全部都完成性誉，那么這就需要LogInfoExecutive負(fù)責(zé)對(duì)多個(gè)并行處理任務(wù)是否完成進(jìn)行判斷了窿吩。

設(shè)計(jì)長(zhǎng)時(shí)處理過(guò)程有三種方法：

方法1：將處理過(guò)程設(shè)計(jì)成一個(gè)組合任務(wù)，使用一個(gè)執(zhí)行組件對(duì)任務(wù)進(jìn)行跟蹤错览，并對(duì)各個(gè)步驟和任務(wù)完成情況進(jìn)行持久化纫雁。
方法2：將處理過(guò)程設(shè)計(jì)成一組聚合，這些聚合在一系列的活動(dòng)中相互協(xié)作倾哺。一個(gè)或多個(gè)聚合實(shí)例充當(dāng)執(zhí)行組件并維護(hù)整個(gè)處理過(guò)程的狀態(tài)先较。
方法3：設(shè)計(jì)一個(gè)無(wú)狀態(tài)的處理過(guò)程携冤，其中每一個(gè)消息處理組件都將對(duì)所接收到的消息進(jìn)行擴(kuò)充——即：向其中加入額外的數(shù)據(jù)信息。然后闲勺，再將消息發(fā)送到下一個(gè)處理組件。在這種方法種扣猫，整個(gè)處理過(guò)程的狀態(tài)包含在每條消息中菜循。

當(dāng)LogInfoExecutive接收到MatchedLogCounted或ExceptionLoginfoCounted事件后，我們需要在領(lǐng)域事件中的每個(gè)任務(wù)中加入獨(dú)特的唯一標(biāo)識(shí)（例如：UUID）申尤，才能判斷到底是哪個(gè)任務(wù)的哪一步執(zhí)行完畢了癌幕。

對(duì)于最簡(jiǎn)單的方式，我們可以將執(zhí)行器和跟蹤器都放到一個(gè)聚合中昧穿，這樣通過(guò)調(diào)用聚合的命令方法勺远，來(lái)觸發(fā)執(zhí)行器和跟蹤器。這樣我們就不需要單獨(dú)的開(kāi)發(fā)一個(gè)跟蹤器來(lái)作為狀態(tài)機(jī)时鸵。

針對(duì)長(zhǎng)時(shí)處理過(guò)程的執(zhí)行器將創(chuàng)建一個(gè)新的類似聚合的狀態(tài)對(duì)象胶逢，用來(lái)跟蹤事件的完成情況。它與相關(guān)的領(lǐng)域事件共享同一個(gè)唯一標(biāo)識(shí)饰潜，用于標(biāo)識(shí)它是用來(lái)維護(hù)某個(gè)長(zhǎng)時(shí)處理的狀態(tài)初坠。在這個(gè)聚合狀態(tài)對(duì)象中，除了包含子任務(wù)的完成狀態(tài)之外彭雾，還包含了對(duì)整體任務(wù)的是否完成狀態(tài)（isCompleted()）和是否超時(shí)狀態(tài)（hasTimeOut()）碟刺。每當(dāng)子任務(wù)完成后，都需要更新對(duì)應(yīng)的狀態(tài)對(duì)象薯酝。那么半沽，如何去更新整體的任務(wù)狀態(tài)呢？一般來(lái)說(shuō)吴菠，有如下兩種處理方式：

被動(dòng)更新：由執(zhí)行器在每次子任務(wù)完成事件到達(dá)時(shí)執(zhí)行completed/timeout者填。
【缺點(diǎn)】如果由于某些原因?qū)е聢?zhí)行器始終接收不到完成領(lǐng)域事件，那么即便處理過(guò)程已經(jīng)超時(shí)橄务，執(zhí)行器還是會(huì)認(rèn)為處理過(guò)程正處于活躍狀態(tài)幔托。

主動(dòng)更新：創(chuàng)建一個(gè)獨(dú)立的定時(shí)器，由它對(duì)任務(wù)的狀態(tài)進(jìn)行管理蜂挪。
【缺點(diǎn)】它需要更多的系統(tǒng)資源重挑，這可能加重系統(tǒng)的運(yùn)行負(fù)擔(dān)。同時(shí)棠涮，定時(shí)器和完成事件之間的競(jìng)態(tài)條件有可能會(huì)造成系統(tǒng)失敗谬哀。