前言

趁著雙十一備戰(zhàn)封板，終于又有一些時(shí)間可以梳理一下最近的心得。

最近這半年跟同事討論比較多的是分層架構(gòu)，然后就會(huì)遇到兩個(gè)觸及靈魂的問題，一個(gè)是如何做好分層架構(gòu)，二是DDD在架構(gòu)層面該如何落地。

為了說好分層，我們需要了解架構(gòu)的意義。

良好的架構(gòu)是為了保證一下兩點(diǎn)：

• 治理應(yīng)用復(fù)雜度，降低系統(tǒng)熵值；
• 從隨心所欲的混亂狀態(tài)，走向井井有條的有序狀態(tài)。

比如，你去圖書館借閱書籍，對(duì)于紛繁雜亂的各類書籍，如果不能很好的管理和分類，必然會(huì)導(dǎo)致圖書館管理混亂，效率低下，使得圖書館不能正常運(yùn)維。而分層架構(gòu)的意義也在于此，當(dāng)我們面對(duì)復(fù)雜的業(yè)務(wù)需求時(shí)，需要更好的規(guī)劃我們的包結(jié)構(gòu)和依賴規(guī)約，可以更好的治理我們的服務(wù)，提升服務(wù)的可維護(hù)性，可擴(kuò)展性，做到我們的架構(gòu)以業(yè)務(wù)為核心，解耦外部依賴，分離業(yè)務(wù)復(fù)雜度和技術(shù)復(fù)雜度。

傳統(tǒng)分層架構(gòu)有MVC，而這些年流行的六邊形架構(gòu)，也是伴隨著DDD的興起而逐步被大家所接受。如果說DDD和六邊形架構(gòu)的關(guān)系，他倆屬于不同層級(jí)的概念，DDD更偏向方法論，注重領(lǐng)域建模和業(yè)務(wù)邏輯的設(shè)計(jì)，強(qiáng)調(diào)將業(yè)務(wù)需求和領(lǐng)域知識(shí)轉(zhuǎn)化為軟件設(shè)計(jì)；而六邊形架構(gòu)更注重系統(tǒng)的整體架構(gòu)和模塊化設(shè)計(jì)，強(qiáng)調(diào)分離內(nèi)部和外部系統(tǒng)的交互。他們倆的結(jié)合是一種非常好的實(shí)踐經(jīng)驗(yàn)， DDD中的領(lǐng)域模型是核心，其他層（如應(yīng)用層、基礎(chǔ)設(shè)施層）依賴于領(lǐng)域模型；而六邊形架構(gòu)正好為DDD提供了一種非常好的分層落地。

淺聊DDD落地

對(duì)于DDD，并沒有一種所謂的框架或者腳手架能夠?qū)?yīng)，其根本原因在于，DDD其實(shí)是一種方法論，而非所謂的框架，它給我們提供了一種應(yīng)對(duì)業(yè)務(wù)復(fù)雜度時(shí)的方法：

• 通過架構(gòu)設(shè)計(jì)來分離業(yè)務(wù)復(fù)雜度和技術(shù)復(fù)雜度；
• 通過限界上下文去做到分而治之，將大系統(tǒng)拆解為若干個(gè)高內(nèi)聚低耦合的子域；
• 通過面向?qū)ο蟮脑O(shè)計(jì)模式，將業(yè)務(wù)子域的知識(shí)進(jìn)行抽象。

總結(jié)一下：

1. DDD的戰(zhàn)略建模注重子域的劃分和限界上下文的定義。對(duì)應(yīng)到落地就是包的拆解， 以及包之間的依賴和組合關(guān)系。
2. 而DDD的戰(zhàn)術(shù)建模主要關(guān)注的是構(gòu)造塊和柔性設(shè)計(jì)。構(gòu)造塊就是我們常說的，類，對(duì)象，組合。而柔性設(shè)計(jì)就是我們面向?qū)ο蟮脑O(shè)計(jì)原則，得到一個(gè)高內(nèi)聚低耦合的系統(tǒng)。所以說，DDD的戰(zhàn)術(shù)建模落地，一定伴隨著開發(fā)人員對(duì)設(shè)計(jì)模式的深刻理解和應(yīng)用。

六邊形分層架構(gòu)

1. App層

應(yīng)用層是DDD中的頂層，負(fù)責(zé)協(xié)調(diào)和組織領(lǐng)域?qū)ο蟮慕换ァＫ邮諄碜杂脩艚缑婊蛲獠肯到y(tǒng)的請(qǐng)求，并將其轉(zhuǎn)發(fā)給領(lǐng)域?qū)舆M(jìn)行處理。應(yīng)用層負(fù)責(zé)定義應(yīng)用的用例（Use Cases），處理事務(wù)邊界和協(xié)調(diào)領(lǐng)域?qū)ο蟮牟僮?。它不包含業(yè)務(wù)邏輯，而是將請(qǐng)求轉(zhuǎn)化為領(lǐng)域?qū)ο蟮牟僮?。?yīng)用層還可以包含獲取輸入，組裝上下文，參數(shù)校驗(yàn)，異常定義，發(fā)送事件通知等。

2. Domain層

主要是封裝了核心業(yè)務(wù)邏輯，并通過領(lǐng)域服務(wù)（Domain Service）和領(lǐng)域?qū)ο螅―omain Entity）的方法對(duì)App層提供業(yè)務(wù)實(shí)體和業(yè)務(wù)邏輯計(jì)算。領(lǐng)域是應(yīng)用的核心，不依賴任何其他層次。同時(shí)領(lǐng)域?qū)訒?huì)有一個(gè)facade層，當(dāng)領(lǐng)域服務(wù)對(duì)外部有調(diào)用依賴時(shí)，通過定義facade接口實(shí)現(xiàn)控制反轉(zhuǎn)。

3. Adapter層

負(fù)責(zé)與外部系統(tǒng)進(jìn)行或者服務(wù)進(jìn)行適配和集成，包括通信，數(shù)據(jù)緩存，接口適配等功能。

此外強(qiáng)調(diào)， RPC consumer調(diào)用放在適配器層。適配器層專注于與外部系統(tǒng)的集成和適配，將外部系統(tǒng)的接口和數(shù)據(jù)格式轉(zhuǎn)換為應(yīng)用程序可以理解和處理的形式。將RPC調(diào)用放在適配器層可以更好地將與外部系統(tǒng)相關(guān)的技術(shù)細(xì)節(jié)與應(yīng)用程序的業(yè)務(wù)邏輯和領(lǐng)域?qū)ο筮M(jìn)行解耦，提高應(yīng)用程序的可擴(kuò)展性和可維護(hù)性。

對(duì)于所有出站適配層，都需要通過實(shí)現(xiàn)facade接口實(shí)現(xiàn)控制反轉(zhuǎn)。

4. 基礎(chǔ)設(shè)施層

負(fù)責(zé)提供支持應(yīng)用程序運(yùn)行的基礎(chǔ)設(shè)施，包括與具體技術(shù)相關(guān)的實(shí)現(xiàn)?；A(chǔ)設(shè)施層通常包括與數(shù)據(jù)庫、消息隊(duì)列、緩存、外部服務(wù)等進(jìn)行交互的代碼，以及一些通用的工具類和配置，也包括filter等實(shí)現(xiàn)。

基礎(chǔ)設(shè)施層和適配器層之間的關(guān)系是：

1. 基礎(chǔ)設(shè)施層提供了與具體技術(shù)相關(guān)的實(shí)現(xiàn)，例如數(shù)據(jù)庫訪問、消息隊(duì)列連接、緩存操作等。適配器層可以使用基礎(chǔ)設(shè)施層提供的功能來與外部系統(tǒng)進(jìn)行交互。
2. 適配器層通過適配器模式或類似的機(jī)制，將外部系統(tǒng)的接口和數(shù)據(jù)格式轉(zhuǎn)換為應(yīng)用程序可以理解和處理的形式。適配器層還負(fù)責(zé)將應(yīng)用程序的請(qǐng)求轉(zhuǎn)發(fā)給基礎(chǔ)設(shè)施層進(jìn)行具體的操作。
3. 基礎(chǔ)設(shè)施層和適配器層一起工作，使得應(yīng)用程序能夠與外部系統(tǒng)進(jìn)行集成，并且將與外部系統(tǒng)相關(guān)的技術(shù)細(xì)節(jié)與應(yīng)用程序的業(yè)務(wù)邏輯和領(lǐng)域?qū)ο筮M(jìn)行解耦。這樣可以實(shí)現(xiàn)應(yīng)用程序的可擴(kuò)展性、可維護(hù)性和可測(cè)試性。

對(duì)于一些無復(fù)雜邏輯的，也可以直接讓上游掉基礎(chǔ)設(shè)施層，不必一定通過Adapter層。

腳手架的落地實(shí)踐

以上主要是理論介紹，基于以上的說明，在實(shí)踐中，我搭建了兩套分層架構(gòu)的java腳手架。具體來說分為單module版本和多module版本。對(duì)于微服務(wù)系統(tǒng)來說，如果你的每個(gè)服務(wù)業(yè)務(wù)復(fù)雜度不高，建議使用單module版本；如果你是個(gè)復(fù)雜業(yè)務(wù)場(chǎng)景的單體應(yīng)用，建議采用多module版本。

1. 單module腳手架

--root
    --application: 應(yīng)用層是程序的入口，整合和組合domain提供的能力。
        --rpc: JSF provider對(duì)外提供的接口實(shí)現(xiàn)
        --controller: springMVC提供的controller
        --listener: MQ消息監(jiān)聽器
        --task: 調(diào)度任務(wù)
        --translate: 將內(nèi)部的BO映射為外部的VO/Entity
        --model: VO對(duì)象
    --adapter: 適配器層
       --rpc: JSF consumer，外部服務(wù)
       --mq: 消息隊(duì)列sender模塊
       --translate: 將外部數(shù)據(jù)結(jié)構(gòu)映射為內(nèi)部的DTO/BO
    --domain: 領(lǐng)域?qū)?       --service: 領(lǐng)域服務(wù)可以按照自己情況靈活設(shè)計(jì)
       --facotry: 工廠
       --event/command: 事件驅(qū)動(dòng)
       --model: 對(duì)象和實(shí)體
       --translate: 對(duì)象實(shí)體映射轉(zhuǎn)換
    --infrastructure:
       --repository: 持久化層，包括db模型，sql讀寫等
       --cache: Redis緩存讀寫
       --producer: MQ消息生成，即發(fā)送MQ消息。
       --config: 配置信息，例如ducc配置、數(shù)據(jù)庫、緩存配置等
       --translate: 將存儲(chǔ)層的數(shù)據(jù)結(jié)構(gòu)PO映射為內(nèi)部的BO
       --utils: 工具集合
    --common: 公共層
       --exception: 主要分為業(yè)務(wù)異常和系統(tǒng)異常。系統(tǒng)異常需要研發(fā)處理。業(yè)務(wù)異常需要具備監(jiān)控能力。
       --utils: 工具類
       --enums: 枚舉類
       --common: 全局公共常量池
    --worker: 異步服務(wù)
    --client: JSF SDK

maven私服拉取腳本如下：

單module版本maven私服拉取腳本如下：

mvn archetype:generate \
            -DarchetypeGroupId=com.jd.magnus \
            -DarchetypeArtifactId=magnus-single-archetype \
            -DarchetypeVersion=1.0.0-SNAPSHOT \
            -DinteractiveMode=false \
            -DarchetypeCatalog=remote \
            -Dversion=1.0.0-SNAPSHOT \
            -DgroupId=com.jdl.sps \
            -DartifactId=bff-single-demo1

2. 多module腳手架

此處有一個(gè)建議，在多module版本下，因?yàn)槭菑?fù)雜單體應(yīng)用，所以建議內(nèi)部進(jìn)行拆包處理。每層內(nèi)也可以基于不同領(lǐng)域場(chǎng)景也可以進(jìn)行拆包操作，每個(gè)場(chǎng)景下層級(jí)結(jié)構(gòu)是一樣的。如下圖舉例,其中app層中分別有兩個(gè)業(yè)務(wù)場(chǎng)景，包括商品和訂單：

多module版本的maven私服拉取腳本如下：

mvn archetype:generate \
            -DarchetypeGroupId=com.jd.magnus \
            -DarchetypeArtifactId=magnus-multi-ddd-archetype \
            -DarchetypeVersion=1.0.0-SNAPSHOT \
            -DinteractiveMode=false \
            -DarchetypeCatalog=remote \
            -Dversion=1.0.0-SNAPSHOT \
            -DgroupId=com.jdl.sps \
            -DartifactId=bff-demo1

小結(jié)

本框架是結(jié)合了DDD思想和六邊形架構(gòu)思想,但腳手架不會(huì)限制大家能力和發(fā)揮。

如果你精通DDD，你可以在domain層采用標(biāo)準(zhǔn)的充血模型和子域拆分模式編寫你的代碼； 如果你精通MVC，該框架也可以簡化為大家熟悉的MVC開發(fā)模式。對(duì)于model的處理，也可靈活應(yīng)對(duì)，在不影響整體代碼架構(gòu)的情況下，允許不過度設(shè)計(jì)及對(duì)象多度封裝，鼓勵(lì)敏捷迭代和定期重構(gòu)。

但有一個(gè)核心思想需要謹(jǐn)記：

我們盡量保證我們的代碼開發(fā)符合開閉原則，能夠通過增加類和方法的方式實(shí)現(xiàn)新功能迭代，盡量就要避免頻繁修改某個(gè)方法或者某個(gè)類，包與包之間要保證高內(nèi)聚，低耦合。因?yàn)镈DD思想的核心就是子域的拆分和對(duì)設(shè)計(jì)模式的合理運(yùn)用。

作者：京東物流 趙勇萍

來源：京東云開發(fā)者社區(qū) 自猿其說 Tech 轉(zhuǎn)載請(qǐng)注明來源文章來源地址http://www.zghlxwxcb.cn/news/detail-746081.html

到了這里，關(guān)于從混亂到優(yōu)雅：基于DDD的六邊形架構(gòu)的代碼翻新指南的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！