微服務(wù)構(gòu)建本質(zhì)上是軟件構(gòu)建過(guò)程中長(zhǎng)期演進(jìn)積累的一系列理念、架構(gòu)原則、工具和最佳實(shí)踐。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的軟件思想體系和方法論可以用于指導(dǎo)微服務(wù)建模、微服務(wù)劃分、微服務(wù)架構(gòu)設(shè)計(jì)等相關(guān)工作，它可以促使技術(shù)人員與領(lǐng)域?qū)＜疫_(dá)成共識(shí)，構(gòu)建領(lǐng)域邊界合理、具備明確界限上下文、關(guān)注點(diǎn)分離、獨(dú)立自治的微服務(wù)。

?領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)概述

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain Driven Design）概念的興起可以追溯到1986 年 ， 《 人 月 神 話 》 的 作 者 Brooks 提 出 軟 件 的 本 質(zhì) 復(fù) 雜 性（Essential Complexity）存在于復(fù)雜的業(yè)務(wù)領(lǐng)域中，技術(shù)僅僅是輔助工具，它解決的問(wèn)題是幫助業(yè)務(wù)領(lǐng)域從現(xiàn)實(shí)問(wèn)題映射轉(zhuǎn)換成軟件實(shí)現(xiàn)。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)在戰(zhàn)略設(shè)計(jì)層面，從業(yè)務(wù)視角出發(fā)使技術(shù)人員專注于問(wèn)題域，從領(lǐng)域?qū)＜夷抢铽@得領(lǐng)域見(jiàn)解，通過(guò)模塊劃分建立領(lǐng)域服務(wù)邊界，通過(guò)界限上下文明確服務(wù)的職責(zé)。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)在戰(zhàn)術(shù)設(shè)計(jì)層面，從技術(shù)的視角出發(fā)，提煉有效的業(yè)務(wù)模型，實(shí)施領(lǐng)域建模、架構(gòu)設(shè)計(jì)完成軟件的落地。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)通過(guò)隔離業(yè)務(wù)與技術(shù)的復(fù)雜性，成為程式化、標(biāo)準(zhǔn)化的軟件架構(gòu)設(shè)計(jì)范式。

軟件復(fù)雜度的來(lái)源

● 業(yè)務(wù)的復(fù)雜性：業(yè)務(wù)的復(fù)雜性體現(xiàn)在業(yè)務(wù)流程不清晰、業(yè)務(wù)參與人員多、業(yè)務(wù)與技術(shù)耦合等方面。在業(yè)務(wù)的早期階段，為了快速滿足功能需求容易形成面條式的代碼風(fēng)格，這樣的代碼風(fēng)格會(huì)導(dǎo)致軟件模塊膨脹、開(kāi)發(fā)效率降低、功能擴(kuò)展步伐放緩、業(yè)務(wù)模型與代碼脫節(jié)等。

● 技術(shù)的復(fù)雜性：技術(shù)的復(fù)雜性來(lái)源于對(duì)項(xiàng)目的質(zhì)量屬性需求，諸如系統(tǒng)的性能、客戶體驗(yàn)、服務(wù)高可用性等。為解決服務(wù)的響應(yīng)延遲、吞吐、安全等問(wèn)題，我們會(huì)引入緩存、消息隊(duì)列、第三方模塊組件，而這些技術(shù)的整合給系統(tǒng)引入了額外的復(fù)雜性和技術(shù)挑戰(zhàn)。

領(lǐng)域驅(qū)動(dòng)解決之道

解決這種軟件構(gòu)建中面臨的復(fù)雜性問(wèn)題，我們需要從領(lǐng)域開(kāi)始著手，與業(yè)務(wù)專家一起獲得領(lǐng)域見(jiàn)解，促使軟件利益干系方在領(lǐng)域內(nèi)建立通用語(yǔ)言。技術(shù)人員通過(guò)建模的手段提煉出事物的本質(zhì)，以便更好地指導(dǎo)應(yīng)用系統(tǒng)的構(gòu)建和規(guī)劃。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中包含了大量成熟的理論、概念、模式和架構(gòu)，它包含一套解決復(fù)雜領(lǐng)域模型的軟件架構(gòu)方法，思想是圍繞業(yè)務(wù)模型來(lái)連接和實(shí)現(xiàn)核心業(yè)務(wù)概念。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)可以讓業(yè)務(wù)和技術(shù)的變化產(chǎn)生的不可預(yù)知因素互相分離，將人員變動(dòng)、團(tuán)隊(duì)規(guī)模、協(xié)作溝通等外界因素變化對(duì)產(chǎn)品和項(xiàng)目的影響封裝在一個(gè)可控的容器和框架下，從而解決軟件面臨的復(fù)雜性問(wèn)題，如下圖所示。

事務(wù)腳本模式與領(lǐng)域建模模式

● 事務(wù)腳本模式：事物腳本模式常見(jiàn)于單體應(yīng)用中，它將所有邏輯全部組織在一個(gè)單一過(guò)程方法中，從數(shù)據(jù)庫(kù)的調(diào)用到不同業(yè)務(wù)邏輯、策略的執(zhí)行全部集成在一個(gè)大的方法塊中。它的好處是簡(jiǎn)單、容易實(shí)現(xiàn)，它的缺點(diǎn)是沒(méi)有自己的狀態(tài)，也無(wú)法擴(kuò)展，容易將服務(wù)組件與數(shù)據(jù)存儲(chǔ)模型之間的剛性依賴引入業(yè)務(wù)邏輯中。

● 領(lǐng)域建模模式：領(lǐng)域建模模式將業(yè)務(wù)邏輯轉(zhuǎn)移到了領(lǐng)域?qū)ο螅―omain Object）中，每個(gè)領(lǐng)域?qū)ο笸瓿蓪儆谧约旱臉I(yè)務(wù)行為。同時(shí)數(shù)據(jù)存儲(chǔ)層的邏輯也變得相對(duì)簡(jiǎn)單，數(shù)據(jù)庫(kù)不再參與領(lǐng)域模型的業(yè)務(wù)邏輯，而是回歸數(shù)據(jù)“持久化”的本質(zhì)。

使用領(lǐng)域模式可以提升系統(tǒng)的內(nèi)聚性和可重用性，通過(guò)不同類之間的協(xié)同完成所有功能。另外，多態(tài)的模式也讓擴(kuò)展新的策略更加方便，業(yè)務(wù)語(yǔ)義更加通用、顯性化。領(lǐng)域建模過(guò)程遵循“SOLID”原則并實(shí)現(xiàn)業(yè)務(wù)域的邏輯解決方案。

說(shuō)明：SOLID原則

1.Single Responsibility Principle：?jiǎn)我宦氊?zé)原則；

2.Open Closed Principle：開(kāi)閉原則3.Liskov Substitution Principle：里氏替換原則；

4.Interface Segregation Principle：接口隔離原則；

5.Dependence Inversion Principle：依賴倒置原則；

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)核心要素

如下圖所示是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心要素，包含領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中的通用模型術(shù)語(yǔ)和重要的戰(zhàn)術(shù)模式。這些模式不僅可以捕獲和傳遞領(lǐng)域中的概念、關(guān)系及邏輯，也能幫助我們管理業(yè)務(wù)的復(fù)雜性并確保領(lǐng)域模型的行為清晰明確。

● 領(lǐng)域：相對(duì)于軟件系統(tǒng)來(lái)說(shuō)就是系統(tǒng)要解決的現(xiàn)實(shí)問(wèn)題。

● 子域：對(duì)于領(lǐng)域進(jìn)行不同維度切分的相對(duì)內(nèi)聚的子系統(tǒng)單元。

● 分層架構(gòu)：通過(guò)分層架構(gòu)將業(yè)務(wù)域和技術(shù)邏輯域隔離。

● 服務(wù)：服務(wù)通常是領(lǐng)域?qū)ο蟮恼{(diào)用方，用來(lái)協(xié)調(diào)領(lǐng)域?qū)ο笸瓿芍付I(yè)務(wù)邏輯職責(zé)。

● 實(shí)體：實(shí)體與面向?qū)ο笾械母拍铑愃疲穷I(lǐng)域模型的基本元素，在領(lǐng)域模型中，實(shí)體應(yīng)該具有唯一的標(biāo)識(shí)符。

● 值對(duì)象：值對(duì)象是沒(méi)有唯一標(biāo)識(shí)符的實(shí)體。值對(duì)象在領(lǐng)域模型中是可以被共享的，它們應(yīng)該是不可變的，當(dāng)有其他地方需要用到值對(duì)象時(shí)，可以將它的副本作為參數(shù)傳遞。

● 聚合：聚合使用邊界將內(nèi)部和外部的對(duì)象劃分開(kāi)來(lái)。每個(gè)聚合有一個(gè)根，這個(gè)根是一個(gè)實(shí)體作為外部可以訪問(wèn)的唯一對(duì)象。

● 資源庫(kù)：是封裝的所有獲取對(duì)象引用所需的邏輯單元。

● 工廠：工廠用來(lái)封裝對(duì)象創(chuàng)建所必需的信息，當(dāng)聚合根建立時(shí)，所有聚合包含的對(duì)象將隨之建立。

專注問(wèn)題域

解決一個(gè)業(yè)務(wù)場(chǎng)景中的復(fù)雜問(wèn)題從理解問(wèn)題域開(kāi)始，通過(guò)專注于問(wèn)題域并理解復(fù)雜問(wèn)題背后的實(shí)質(zhì)，你才能設(shè)計(jì)有效的模型來(lái)應(yīng)對(duì)業(yè)務(wù)的挑戰(zhàn)。在項(xiàng)目初期，盡量避免沉溺于技術(shù)實(shí)現(xiàn)，而要把焦點(diǎn)集中在問(wèn)題領(lǐng)域，不要忘記技術(shù)服務(wù)業(yè)務(wù)的原則。

理解問(wèn)題域

我們以一個(gè)金融場(chǎng)景下的“業(yè)務(wù)運(yùn)營(yíng)監(jiān)控系統(tǒng)”為例進(jìn)行分析。

經(jīng)過(guò)與運(yùn)營(yíng)管理專家和相關(guān)業(yè)務(wù)方的多輪需求探論，我們初步了解了用戶的業(yè)務(wù)訴求和痛點(diǎn)。需要強(qiáng)調(diào)的是對(duì)于問(wèn)題域的充分理解是我們的首要任務(wù)。

這里整理了一份需求文檔，它詳細(xì)地記錄了問(wèn)題域的具體范圍和詳細(xì)需求。這份文檔不僅是業(yè)務(wù)與技術(shù)團(tuán)隊(duì)之間的一份溝通文檔，也可以作為軟件生命周期在需求分析階段的一個(gè)清晰的、規(guī)范化的知識(shí)協(xié)作產(chǎn)物。

提煉問(wèn)題域

理解復(fù)雜問(wèn)題并從中識(shí)別、提煉出關(guān)鍵的業(yè)務(wù)模型，即提煉問(wèn)題域是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的關(guān)鍵環(huán)節(jié)。團(tuán)隊(duì)可以通過(guò)頭腦風(fēng)暴的形式羅列出領(lǐng)域中的所有事件，整合之后形成最終的領(lǐng)域事件集合。

你需要在關(guān)鍵事件標(biāo)記的范圍里，參照不同利益干系方的業(yè)務(wù)訴求，組織領(lǐng)域事件和模型，同時(shí)，你需要整理出與項(xiàng)目關(guān)聯(lián)的上下游系統(tǒng)，如下圖所示。

通過(guò)挖掘隱藏在領(lǐng)域事件中的核心領(lǐng)域模型，我們可以找到從問(wèn)題空間到方案空間的對(duì)應(yīng)映射關(guān)系。針對(duì)上述業(yè)務(wù)監(jiān)控系統(tǒng)案例，“進(jìn)件存量”和“進(jìn)件流量”的概念成為我們發(fā)現(xiàn)的重要領(lǐng)域模型。

作為衡量業(yè)務(wù)系統(tǒng)運(yùn)轉(zhuǎn)狀態(tài)的重要指標(biāo)，業(yè)務(wù)的“存量”狀態(tài)可以表示業(yè)務(wù)的積壓情況，而業(yè)務(wù)的“流量”狀態(tài)可以表示業(yè)務(wù)流轉(zhuǎn)的變化情況。

如下圖所示是我們總結(jié)的監(jiān)控系統(tǒng)概要視圖，其中實(shí)線表示的是城市信貸業(yè)務(wù)工作流中進(jìn)件在不同系統(tǒng)的流向，而虛線表示的則是業(yè)務(wù)的存量、流量在業(yè)務(wù)監(jiān)控系統(tǒng)的事件記錄。

服務(wù)的拆分

完成問(wèn)題域的理解和提煉后，我們需要對(duì)整體系統(tǒng)做進(jìn)一步的服務(wù)拆分。下圖是我們根據(jù)業(yè)務(wù)領(lǐng)域能力對(duì)“業(yè)務(wù)運(yùn)營(yíng)監(jiān)控系統(tǒng)”進(jìn)行拆分后的子領(lǐng)域服務(wù)及模塊劃分說(shuō)明。

● 業(yè)務(wù)事件收集（如下圖和表所示）

● 事件過(guò)濾聚合（如下圖和表所示）

● 規(guī)則配置（如下圖和表所示）

● 監(jiān)控查詢展示（如下圖和表所示）

為什么要做服務(wù)拆分

● 降低系統(tǒng)的整體復(fù)雜性：根據(jù)業(yè)務(wù)領(lǐng)域進(jìn)行合理的服務(wù)拆分是一個(gè)有效控制系統(tǒng)復(fù)雜性的方法。

● 提高效率：服務(wù)拆分后，代碼模塊相互隔離，并發(fā)的開(kāi)發(fā)模式可以提升開(kāi)發(fā)人員的效率。

● 團(tuán)隊(duì)人員各司其職：拆分的項(xiàng)目可分派給擅長(zhǎng)相關(guān)方面技術(shù)的人員，讓團(tuán)隊(duì)成員各司其職，降低工作的耦合度。

● 共享和自治：可以通過(guò)定義好的服務(wù)接口進(jìn)行服務(wù)共享，同時(shí)拆分后的服務(wù)也更加自治。

● 解決依賴問(wèn)題：通過(guò)服務(wù)拆分，可以清晰地了解哪些服務(wù)依賴會(huì)對(duì)業(yè)務(wù)造成影響，從而準(zhǔn)備預(yù)案。

服務(wù)拆分的依據(jù)

高內(nèi)聚、低耦合是服務(wù)拆分的主要依據(jù)，下面我們列舉一些常用的服務(wù)拆分策略，了解如何對(duì)單體架構(gòu)進(jìn)行拆分。

● 區(qū)分服務(wù)類型：工具服務(wù)區(qū)別于業(yè)務(wù)服務(wù)，它的特點(diǎn)是與業(yè)務(wù)領(lǐng)域無(wú)關(guān)，根據(jù)其用途可以進(jìn)一步細(xì)分，一般包括的形式有公共工具服務(wù)、資源工具服務(wù)、包裝器服務(wù)等。

● 根據(jù)功能定義劃分服務(wù)：領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)通過(guò)分析問(wèn)題空間和業(yè)務(wù)邏輯，將應(yīng)用程序定義為域，域由多個(gè)子域組成，每個(gè)子域?qū)?yīng)于業(yè)務(wù)的不同功能部分。

● 根據(jù)技術(shù)邊界劃分服務(wù)：對(duì)于產(chǎn)品類型的服務(wù)使用技術(shù)能力劃分服務(wù)邊界，前后端分離架構(gòu)就是通過(guò)技術(shù)棧劃分服務(wù)邊界的典型架構(gòu)模式。

服務(wù)拆分范式

通過(guò)增加服務(wù)實(shí)例或者機(jī)器來(lái)解決服務(wù)的容量和可用性問(wèn)題是常用的可擴(kuò)展架構(gòu)解決方案。在《可擴(kuò)展藝術(shù)》一書(shū)中提出了系統(tǒng)的可擴(kuò)展性模型：AKF可擴(kuò)展立方，可以作為服務(wù)拆分的范式。

如下圖所示是使用Scale Cube的3D模型實(shí)現(xiàn)的一個(gè)微服務(wù)架構(gòu)模型，在X軸上通過(guò)API網(wǎng)關(guān)進(jìn)行水平擴(kuò)展，在Y軸上進(jìn)行單體拆分后的微服務(wù)構(gòu)建，服務(wù)之間可以通過(guò)REST API進(jìn)行簡(jiǎn)單交互，Z軸是數(shù)據(jù)維度的拆分。

● X軸：服務(wù)擴(kuò)展，通過(guò)克隆的方式水平擴(kuò)展。一般是負(fù)載均衡后運(yùn)行多個(gè)應(yīng)用副本，達(dá)到某個(gè)服務(wù)的高吞吐量和高可用性。

● Y軸：功能拆分，通過(guò)拆分不同的事務(wù)進(jìn)行擴(kuò)展。微服務(wù)對(duì)應(yīng)著Y軸，即將單體應(yīng)用拆分為微服務(wù)應(yīng)用。

● Z軸：數(shù)據(jù)分區(qū)，通過(guò)分隔相同的事務(wù)進(jìn)行擴(kuò)展，例如數(shù)據(jù)庫(kù)分庫(kù)分表。

總之，服務(wù)支持水平擴(kuò)展以提升容量；對(duì)功能的拆分體現(xiàn)在對(duì)業(yè)務(wù)模型的切入和深入理解上；應(yīng)用數(shù)據(jù)的劃分是微服務(wù)的重要原則，如果數(shù)據(jù)的耦合問(wèn)題無(wú)法解決，那么應(yīng)用服務(wù)的劃分還會(huì)有代碼耦合和級(jí)聯(lián)影響。

界限上下文

在找到服務(wù)邊界并把系統(tǒng)拆分后，我們需要使用“界限上下文”的概念明確服務(wù)之間的交互共享模型和行為接口，它不僅可以有效地限定領(lǐng)域的職責(zé)邊界和特性范圍，也可以控制問(wèn)題域的規(guī)模，進(jìn)而以化整為零的方式控制整個(gè)系統(tǒng)的復(fù)雜性。

在業(yè)務(wù)運(yùn)營(yíng)監(jiān)控項(xiàng)目中，存量項(xiàng)模型作為業(yè)務(wù)過(guò)濾聚合服務(wù)和存量查詢統(tǒng)計(jì)服務(wù)的共享模型，關(guān)系如下圖所示。

為了實(shí)現(xiàn)捕獲和統(tǒng)計(jì)監(jiān)控業(yè)務(wù)運(yùn)營(yíng)過(guò)程中的不同階段存量的業(yè)務(wù)狀態(tài)，我們將存量項(xiàng)作為上述兩個(gè)服務(wù)上下文的共享模型，但我們不會(huì)暴露“過(guò)濾聚合服務(wù)”中的存量明細(xì)、Flow、Stream等模塊的實(shí)現(xiàn)細(xì)節(jié)。

作為兩個(gè)獨(dú)立的服務(wù)主體，它們應(yīng)該在邊界上有明確的界線劃分和通信機(jī)制。如果服務(wù)邊界與領(lǐng)域的界限上下文能夠保持一致，那么我們已經(jīng)為高內(nèi)聚、低耦合的微服務(wù)架構(gòu)實(shí)現(xiàn)了關(guān)鍵的一步。

領(lǐng)域建模

領(lǐng)域建模是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心，通過(guò)領(lǐng)域模型可以封裝對(duì)業(yè)務(wù)的抽象，建立業(yè)務(wù)概念與領(lǐng)域規(guī)則的關(guān)系。領(lǐng)域模型更關(guān)注的是業(yè)務(wù)語(yǔ)義的顯性表達(dá)，而不是具體的數(shù)據(jù)存儲(chǔ)及代碼邏輯實(shí)現(xiàn)細(xì)節(jié)，它可以有效地降低業(yè)務(wù)人員和技術(shù)人員之間的溝通成本。

案例分析

回到“業(yè)務(wù)運(yùn)營(yíng)監(jiān)控系統(tǒng)”中，我們把業(yè)務(wù)監(jiān)控的核心訴求聚焦在“業(yè)務(wù)事件”，以及業(yè)務(wù)的存量和流量領(lǐng)域模型。在整理了領(lǐng)域服務(wù)的核心模塊后，我們可以把業(yè)務(wù)方關(guān)注的組織信息、業(yè)務(wù)類型信息、業(yè)務(wù)階段信息進(jìn)行進(jìn)一步領(lǐng)域模型細(xì)化，如下圖所示。

● BizEvent：業(yè)務(wù)事件是業(yè)務(wù)監(jiān)控的數(shù)據(jù)源，使用統(tǒng)一的JSON格式記錄消息事件，以日志方式封裝當(dāng)前業(yè)務(wù)系統(tǒng)發(fā)生的事件詳情。

● Stream：對(duì)應(yīng)一個(gè)端到端的數(shù)據(jù)流轉(zhuǎn)概念，通常我們會(huì)將BizEvent事件發(fā)送到Kafka的一個(gè)Topic上，通過(guò)建立Stream可以在消費(fèi)端處理指定Topic上的數(shù)據(jù)流。

● Flow：Flow對(duì)應(yīng)一個(gè)監(jiān)控業(yè)務(wù)計(jì)算邏輯，存量Flow可以統(tǒng)計(jì)對(duì)應(yīng)的存量狀態(tài)，流量Flow統(tǒng)計(jì)當(dāng)前業(yè)務(wù)的流量狀態(tài)。

● Service：它并非領(lǐng)域?qū)ο螅硎疽粋€(gè)通用的服務(wù)層，Service提供業(yè)務(wù)存量和流量的查詢、備份、預(yù)警等業(yè)務(wù)方法。

● Provision：用戶配置前置通用服務(wù)，不對(duì)應(yīng)領(lǐng)域?qū)ο螅饕邮沼脩舻呐渲谜?qǐng)求，并保存為業(yè)務(wù)規(guī)則。

● Rule：即規(guī)則模型，屬于核心領(lǐng)域模型，業(yè)務(wù)方可以通過(guò)它靈活地定制關(guān)心的業(yè)務(wù)狀態(tài)并進(jìn)行預(yù)警、過(guò)濾等。

● Detail：屬于業(yè)務(wù)的中間監(jiān)控過(guò)程詳情，屬于領(lǐng)域?qū)ο螅瑫r(shí)包含組織、階段、業(yè)務(wù)類型等明細(xì)對(duì)象屬性（Org、Phase、BizType）。

使用領(lǐng)域建模的設(shè)計(jì)方法可以進(jìn)一步將“業(yè)務(wù)監(jiān)控系統(tǒng)”內(nèi)部的領(lǐng)域服務(wù)與領(lǐng)域模型對(duì)象關(guān)聯(lián)，顯性地表達(dá)每個(gè)領(lǐng)域模型的具體工作職責(zé)及業(yè)務(wù)行為事件與領(lǐng)域?qū)ο笾g的上下文映射關(guān)系，如下圖所示。

架構(gòu)設(shè)計(jì)

架構(gòu)設(shè)計(jì)的本質(zhì)是管理業(yè)務(wù)和技術(shù)復(fù)雜性，使系統(tǒng)易于有序化重構(gòu)及擴(kuò)展。高質(zhì)量的架構(gòu)一定是高度抽象的、圍繞業(yè)務(wù)的、易于理解的、面向演進(jìn)的。

分層架構(gòu)設(shè)計(jì)

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)遵循“關(guān)注點(diǎn)分離”原則，將技術(shù)實(shí)現(xiàn)邏輯封裝在基礎(chǔ)設(shè)施層；將業(yè)務(wù)邏輯封裝在領(lǐng)域?qū)樱M量使領(lǐng)域?qū)哟a與其他層技術(shù)細(xì)節(jié)分割開(kāi)來(lái)；將應(yīng)用層作為黏合劑，實(shí)現(xiàn)前兩者的協(xié)作；同時(shí)UI層可以基于Swagger技術(shù)暴露REST API。分層架構(gòu)如下圖所示。

六邊形（Hexagonal）架構(gòu)模式

六邊形架構(gòu)模式又稱為“端口-適配器”模式，它將系統(tǒng)分為內(nèi)部和外部。內(nèi)部代表應(yīng)用的業(yè)務(wù)邏輯，外部代表應(yīng)用的驅(qū)動(dòng)邏輯、基礎(chǔ)設(shè)施或其他應(yīng)用。內(nèi)部以API接口呈現(xiàn)，通過(guò)端口和外部系統(tǒng)通信。外部系統(tǒng)需要使用不同的適配器，適配器負(fù)責(zé)對(duì)協(xié)議進(jìn)行轉(zhuǎn)換。應(yīng)用程序能夠以一致的方式與實(shí)際運(yùn)行的設(shè)備和數(shù)據(jù)庫(kù)相隔離，方便開(kāi)發(fā)和測(cè)試，六邊形架構(gòu)模式如下圖所示。

微服務(wù)架構(gòu)模式

微服務(wù)架構(gòu)是強(qiáng)調(diào)細(xì)粒度、單一職責(zé)的架構(gòu)模式。微服務(wù)架構(gòu)更關(guān)注的是系統(tǒng)的非功能需求：質(zhì)量屬性、演進(jìn)能力、擴(kuò)展性、觀測(cè)性、軟件交付效率等。微服務(wù)使用CQRS（命令/查詢職責(zé)分離）中的事務(wù)腳本模式應(yīng)對(duì)查詢場(chǎng)景，而對(duì)于復(fù)雜的業(yè)務(wù)邏輯場(chǎng)景，使用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)模式。微服務(wù)架構(gòu)模式如下圖所示。

本文給大家講解的內(nèi)容是微服務(wù)架構(gòu)深度解析：微服務(wù)構(gòu)建，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

1. 下篇文章給大家講解的是微服務(wù)架構(gòu)深度解析：微服務(wù)構(gòu)建，微服務(wù)化改造

2. 覺(jué)得文章不錯(cuò)的朋友可以轉(zhuǎn)發(fā)此文關(guān)注小編；

3. 感謝大家的支持！