領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD在IT企業(yè)內(nèi)部網(wǎng)站開(kāi)發(fā)中的運(yùn)用

摘要：在企業(yè)內(nèi)部網(wǎng)站的建設(shè)過(guò)程中，網(wǎng)站后端最初采用傳統(tǒng)的表模式的開(kāi)發(fā)方式。這種方式極易導(dǎo)致站點(diǎn)的核心業(yè)務(wù)邏輯和業(yè)務(wù)規(guī)則分布在架構(gòu)的各個(gè)層和對(duì)象中，這使得系統(tǒng)業(yè)務(wù)邏輯的復(fù)用性不高。為了解決這個(gè)問(wèn)題，作者在后期的開(kāi)發(fā)過(guò)程中引入了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的開(kāi)發(fā)方式，把系統(tǒng)的業(yè)務(wù)邏輯獨(dú)立建模、充分地復(fù)用，并基于這些模型打造易于擴(kuò)展的開(kāi)發(fā)框架，提高了整個(gè)團(tuán)隊(duì)開(kāi)發(fā)業(yè)務(wù)邏輯的效率，最終網(wǎng)站如期上線，穩(wěn)定運(yùn)行至今。

關(guān)鍵詞：表模式;貧血模型;領(lǐng)域驅(qū)動(dòng)設(shè)計(jì);領(lǐng)域模型

中圖分類號(hào)：TP311? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2022）10-0044-04

數(shù)字化是每個(gè)IT企業(yè)系統(tǒng)建設(shè)必不可少的一個(gè)環(huán)節(jié)，而企業(yè)內(nèi)部網(wǎng)站往往也是數(shù)字化的重要標(biāo)志和組成部分。企業(yè)內(nèi)部站點(diǎn)建設(shè)項(xiàng)目就是在這種場(chǎng)景下誕生的，主要就是為順利開(kāi)展研發(fā)部門的日常工作，提供所需的管理各項(xiàng)流程制度的功能。

在項(xiàng)目的開(kāi)始階段，作者在研發(fā)方式上選擇了常見(jiàn)的表模式來(lái)開(kāi)發(fā)網(wǎng)站后端，在架構(gòu)上選用了傳統(tǒng)的多層架構(gòu)來(lái)組織代碼。這種技術(shù)選型和搭配常用于開(kāi)發(fā)業(yè)務(wù)邏輯比較簡(jiǎn)單的小型項(xiàng)目，整個(gè)開(kāi)發(fā)的過(guò)程都聚焦在具體的數(shù)據(jù)庫(kù)設(shè)計(jì)和面向流程的開(kāi)發(fā)上，對(duì)于團(tuán)隊(duì)成員來(lái)說(shuō)簡(jiǎn)單易于上手。

不過(guò)，當(dāng)網(wǎng)站的功能逐漸增多以后，系統(tǒng)的復(fù)雜度迅速攀升，采用這種搭配使得系統(tǒng)的業(yè)務(wù)邏輯得不到聚焦，最終它們零散地分布在架構(gòu)的各個(gè)層和對(duì)象中，業(yè)務(wù)邏輯的復(fù)用性很差。

為了解決這個(gè)問(wèn)題，作者引入了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的開(kāi)發(fā)方式。這種開(kāi)發(fā)方式聚焦于多變的業(yè)務(wù)邏輯，把它們作為系統(tǒng)開(kāi)發(fā)的核心模型管理起來(lái)，這樣就使得系統(tǒng)的業(yè)務(wù)邏輯得到了充分的復(fù)用，整個(gè)團(tuán)隊(duì)開(kāi)發(fā)的效率就得到了顯著的提高。

1 軟件開(kāi)發(fā)的三種模式

在軟件開(kāi)發(fā)中，根據(jù)研發(fā)過(guò)程的不同，一般把開(kāi)發(fā)流程分為事務(wù)腳本、表模式和領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)三種模式。

1.1 事務(wù)腳本

1） 模式介紹

時(shí)至今日，雖然主流編程語(yǔ)言都是面向?qū)ο笳Z(yǔ)言，但是很多團(tuán)隊(duì)都是采用面向過(guò)程的開(kāi)發(fā)模式，代碼中使用的對(duì)象并沒(méi)有實(shí)際的意義，純粹只是代碼腳本的載體。

事務(wù)腳本（Transaction Script） 就是這樣一種簡(jiǎn)單的開(kāi)發(fā)模式，它完全采用的是面向過(guò)程的做法，直接將用戶在表現(xiàn)層上所做的操作翻譯成代碼腳本（比如SQL語(yǔ)句、批處理語(yǔ)句等） 執(zhí)行的模式[1]。

2） 實(shí)現(xiàn)方式

通常，實(shí)現(xiàn)事務(wù)腳本模式不會(huì)進(jìn)行對(duì)象設(shè)計(jì)，也不會(huì)對(duì)涉及的組件進(jìn)行分層，所有從表現(xiàn)層到底層的操作全部放到一起。

典型的例子就比如展示圖書列表的頁(yè)面，開(kāi)發(fā)的時(shí)候通常就是在界面上放置一個(gè)列表控件，然后該控件直接綁定從數(shù)據(jù)庫(kù)中獲取圖書的SQL語(yǔ)句進(jìn)行數(shù)據(jù)填充。增加和修改圖書的時(shí)候也是類似，直接提供SQL語(yǔ)句操作數(shù)據(jù)庫(kù)。

當(dāng)然，為了使整個(gè)程序的結(jié)構(gòu)更加清晰，在使用事務(wù)腳本模式時(shí)，很多團(tuán)隊(duì)也會(huì)進(jìn)行簡(jiǎn)單的分層，這就是基本的多層架構(gòu)的由來(lái)，也就是把應(yīng)用分為如圖1所示的三層。

在分層架構(gòu)下，應(yīng)用把整個(gè)業(yè)務(wù)流程分割并組織在不同的層級(jí)中，與用戶直接交互的組件放在表現(xiàn)層中，用戶在表現(xiàn)層的操作會(huì)被翻譯成系統(tǒng)的輸入數(shù)據(jù)模型并進(jìn)入業(yè)務(wù)邏輯層，業(yè)務(wù)邏輯層再調(diào)用底層的數(shù)據(jù)訪問(wèn)層的腳本操作數(shù)據(jù)庫(kù)、文件系統(tǒng)等數(shù)據(jù)源，完成業(yè)務(wù)邏輯。

在這個(gè)過(guò)程中，系統(tǒng)設(shè)計(jì)的重點(diǎn)依然是面向過(guò)程的，各個(gè)層和對(duì)象只是過(guò)程的載體，具體叫什么其實(shí)并沒(méi)有什么太大的區(qū)別。

3） 應(yīng)用場(chǎng)景

事務(wù)腳本是一種常用的開(kāi)發(fā)模式，針對(duì)那些交互邏輯簡(jiǎn)單，業(yè)務(wù)模式幾乎不會(huì)改變和發(fā)展的簡(jiǎn)單場(chǎng)景，比如常見(jiàn)的“增刪改查型”應(yīng)用，整個(gè)開(kāi)發(fā)過(guò)程的效率會(huì)非常高。

1.2 表模式

1） 模式介紹

在研發(fā)過(guò)程中，數(shù)據(jù)庫(kù)作為最重要的數(shù)據(jù)載體，在任何一個(gè)項(xiàng)目的開(kāi)發(fā)過(guò)程中幾乎是必然會(huì)出現(xiàn)的。在事務(wù)腳本中，與數(shù)據(jù)庫(kù)交互基本都是通過(guò)在代碼中直接使用SQL語(yǔ)句來(lái)完成的。

在常見(jiàn)的編程語(yǔ)言中，SQL語(yǔ)句都是作為字符串存在的，這就帶來(lái)一個(gè)問(wèn)題，由于字符串的內(nèi)容不參與編譯，所以如果SQL語(yǔ)句存在語(yǔ)法問(wèn)題，那就只能到了應(yīng)用運(yùn)行時(shí)產(chǎn)生錯(cuò)誤才會(huì)被發(fā)現(xiàn)，編譯時(shí)發(fā)現(xiàn)不了，這有時(shí)會(huì)帶來(lái)潛在的發(fā)布風(fēng)險(xiǎn)。

為了優(yōu)化操作數(shù)據(jù)庫(kù)的體驗(yàn)，提高代碼編寫的效率，在數(shù)據(jù)訪問(wèn)層，經(jīng)過(guò)工程師們不斷地嘗試和努力，就出現(xiàn)了一種全新的數(shù)據(jù)交互方式，這就是通過(guò)編程語(yǔ)言中的實(shí)體對(duì)象來(lái)操作數(shù)據(jù)庫(kù)中的數(shù)據(jù)。

根據(jù)實(shí)體影響數(shù)據(jù)庫(kù)中數(shù)據(jù)的具體實(shí)現(xiàn)不同，以最為核心的表操作為例，如果一個(gè)實(shí)體對(duì)象能執(zhí)行數(shù)據(jù)庫(kù)表中多條數(shù)據(jù)的相關(guān)操作，那么這種模式就稱為“表模式（Table Module） ”，如果一個(gè)實(shí)體對(duì)象只執(zhí)行表中一條數(shù)據(jù)的相關(guān)操作，那么這種模式就稱為“活動(dòng)記錄（Active Record） ”。這兩種模式本質(zhì)上并沒(méi)有太大的區(qū)別。

2） 實(shí)現(xiàn)方式

以表模式為例，從具體實(shí)踐上來(lái)說(shuō)，它們是在事務(wù)腳本的基礎(chǔ)上，把腳本操作變成了對(duì)象的操作。這個(gè)過(guò)程一般是通過(guò)特定的框架來(lái)完成的，這種框架一般被稱為“對(duì)象關(guān)系映射（Object Relational Mapping，以下簡(jiǎn)稱ORM） ”。

ORM框架把關(guān)系數(shù)據(jù)庫(kù)中的結(jié)構(gòu)映射成語(yǔ)言中的實(shí)體對(duì)象，當(dāng)調(diào)用實(shí)體的方法的時(shí)候，ORM框架就會(huì)將對(duì)象操作翻譯成SQL語(yǔ)句，然后作用于數(shù)據(jù)庫(kù)，如圖2所示。

從具體實(shí)踐上來(lái)說(shuō)，該模式在事務(wù)腳本的基礎(chǔ)上，把腳本操作變成了對(duì)象的操作。由于這些對(duì)象只是數(shù)據(jù)庫(kù)中表的映射，只具有保存數(shù)據(jù)的字段，而沒(méi)有任何實(shí)際的業(yè)務(wù)操作，所以，這些實(shí)體對(duì)象一般也被稱為“貧血模型”。

3） 應(yīng)用場(chǎng)景

表模式優(yōu)化了數(shù)據(jù)庫(kù)訪問(wèn)的體驗(yàn)，但是并不涉及任何業(yè)務(wù)邏輯的處理，所以表模式和事務(wù)腳本一樣，都非常適合那些業(yè)務(wù)邏輯簡(jiǎn)單的場(chǎng)景，對(duì)于較為復(fù)雜的應(yīng)用場(chǎng)景則不太合適。

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

1） 模式介紹

事務(wù)腳本和表模式兩種開(kāi)發(fā)模式，主要采用的是面向過(guò)程的編程方法，而且在應(yīng)用開(kāi)發(fā)的過(guò)程中，需求分析和系統(tǒng)設(shè)計(jì)大都是分離的，這樣就把應(yīng)用開(kāi)發(fā)前期的工作割裂開(kāi)來(lái)，這也就導(dǎo)致了需求分析的結(jié)果與系統(tǒng)設(shè)計(jì)的代碼不能完全匹配，以至于軟件上線后，客戶才發(fā)現(xiàn)許多功能不是自己想要的。

不同于這兩種模式，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain Driven Design，以下簡(jiǎn)稱DDD） 開(kāi)發(fā)模式是純粹的面向?qū)ο蟮脑O(shè)計(jì)過(guò)程，它以業(yè)務(wù)領(lǐng)域?yàn)楹诵?，分析領(lǐng)域中的問(wèn)題，通過(guò)設(shè)計(jì)和建立對(duì)應(yīng)的“領(lǐng)域模型（對(duì)象） ”來(lái)有效的解決領(lǐng)域中的核心問(wèn)題[2]。

在上述的過(guò)程中，通過(guò)“領(lǐng)域分析”到“領(lǐng)域建?！?，DDD統(tǒng)一了需求分析和設(shè)計(jì)編碼兩個(gè)階段，這使得軟件能夠靈活快速的跟隨需求的變化而變化。

在編程實(shí)踐上，DDD豐富了實(shí)體類的行為，把業(yè)務(wù)邏輯也封裝到了實(shí)體類中，實(shí)體類成為承載系統(tǒng)核心業(yè)務(wù)邏輯和規(guī)則的載體，實(shí)體類是整個(gè)應(yīng)用設(shè)計(jì)的核心。

要復(fù)用業(yè)務(wù)邏輯，就是要復(fù)用這些實(shí)體類，為了更好地做到這一點(diǎn)，在DDD中，就把實(shí)體類相關(guān)的模型都聚攏到一起，放到領(lǐng)域模型層中。

2） 實(shí)現(xiàn)方式

DDD是一種設(shè)計(jì)思路，為了實(shí)現(xiàn)聚焦業(yè)務(wù)邏輯，構(gòu)建領(lǐng)域模型的目的，具體實(shí)施時(shí)一般分為戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)兩個(gè)階段。

戰(zhàn)略設(shè)計(jì)階段主要完成的工作是識(shí)別應(yīng)用的領(lǐng)域，將領(lǐng)域細(xì)化得到子域，為每個(gè)子域設(shè)計(jì)限界上下文，并在這個(gè)過(guò)程中，通過(guò)與業(yè)務(wù)專家的充分討論，得到描述業(yè)務(wù)的統(tǒng)一語(yǔ)言。

戰(zhàn)術(shù)設(shè)計(jì)階段完成的工作是根據(jù)限界上下文和統(tǒng)一語(yǔ)言，設(shè)計(jì)領(lǐng)域?qū)又械念I(lǐng)域模型對(duì)象，具體包括實(shí)體、值對(duì)象、領(lǐng)域事件、倉(cāng)儲(chǔ)、聚合和領(lǐng)域服務(wù)等（具體概念和細(xì)節(jié)可以參見(jiàn)文獻(xiàn)[3]） 。

DDD的具體實(shí)現(xiàn)也存在多種形式，本次網(wǎng)站的實(shí)踐采用的就是經(jīng)典的DDD的分層架構(gòu)，整體架構(gòu)圖如圖3所示。

表現(xiàn)層與以往的架構(gòu)相同，主要是與用戶交互的界面元素。

應(yīng)用服務(wù)層是薄薄的一層，主要是把用戶的輸入轉(zhuǎn)換成系統(tǒng)需要的數(shù)據(jù)模型和把系統(tǒng)生成的數(shù)據(jù)模型轉(zhuǎn)化成表現(xiàn)層需要的對(duì)象模型，需要注意的是應(yīng)用服務(wù)層主要完成轉(zhuǎn)換和交接工作，調(diào)用基礎(chǔ)設(shè)施完成一些諸如持久化的工作，千萬(wàn)不能實(shí)現(xiàn)任何的業(yè)務(wù)邏輯。

領(lǐng)域?qū)邮钦麄€(gè)系統(tǒng)的核心層，它包含所有的領(lǐng)域模型。這些領(lǐng)域模型承載和實(shí)現(xiàn)了所有的業(yè)務(wù)邏輯和業(yè)務(wù)規(guī)則，所有的其他層都依賴于領(lǐng)域?qū)?，但是領(lǐng)域?qū)硬粫?huì)依賴于任何其他層。

基礎(chǔ)設(shè)施層完成了的一些輔助的功能，比如一些第三方類庫(kù)、具體的持久化實(shí)現(xiàn)如ORM等。

當(dāng)按照DDD走完代碼設(shè)計(jì)的過(guò)程以后，領(lǐng)域模型就封裝了所有的業(yè)務(wù)邏輯，這樣復(fù)用領(lǐng)域模型就可以復(fù)用整個(gè)業(yè)務(wù)邏輯，同時(shí)也能保證這部分復(fù)雜多變的邏輯被單獨(dú)地隔離起來(lái)，不會(huì)對(duì)系統(tǒng)其他部分存在影響。

3） 應(yīng)用場(chǎng)景

DDD開(kāi)發(fā)模式特別適用于那些業(yè)務(wù)場(chǎng)景比較復(fù)雜、業(yè)務(wù)邏輯變化比較頻繁、系統(tǒng)復(fù)雜度比較高的場(chǎng)景，典型的就比如中臺(tái)系統(tǒng)的搭建[4]、微服務(wù)的開(kāi)發(fā)[5]。

2 開(kāi)發(fā)模式的應(yīng)用

2.1 初期采用表模式開(kāi)發(fā)模式

在最初的開(kāi)發(fā)過(guò)程中，作者帶領(lǐng)團(tuán)隊(duì)采用表模式開(kāi)發(fā)系統(tǒng)，也就是每個(gè)業(yè)務(wù)功能的開(kāi)發(fā)都遵循如下的流程：

1） 根據(jù)業(yè)務(wù)的需求分析得到數(shù)據(jù)表的字段，把數(shù)據(jù)庫(kù)表建好。

2） 通過(guò)ORM將數(shù)據(jù)庫(kù)中的表映射成代碼中的實(shí)體對(duì)象。

3） 在業(yè)務(wù)邏輯層根據(jù)功能的需要補(bǔ)充業(yè)務(wù)邏輯和規(guī)則，操作實(shí)體對(duì)象進(jìn)行數(shù)據(jù)的讀取和持久化。

這種開(kāi)發(fā)方式簡(jiǎn)單易行，但是隨著網(wǎng)站的功能逐漸增多，邏輯越發(fā)地復(fù)雜，如下問(wèn)題逐漸顯現(xiàn)出來(lái)：

1） 通過(guò)ORM得到的實(shí)體對(duì)象都是貧血模型，它們只有數(shù)據(jù)庫(kù)映射的屬性和字段，并不具有具體的業(yè)務(wù)行為。

2） 因?yàn)闆](méi)有明確的約束，核心業(yè)務(wù)邏輯和業(yè)務(wù)規(guī)則非常容易從業(yè)務(wù)邏輯層擴(kuò)散到其他層和對(duì)象中。有的跑到了幫助類中、有的跑到了存儲(chǔ)過(guò)程里，這導(dǎo)致了業(yè)務(wù)邏輯的復(fù)用性不高。

為了解決上述問(wèn)題，作者再次深入研究了上述的軟件開(kāi)發(fā)模式并決定引入DDD來(lái)開(kāi)發(fā)和管理項(xiàng)目。

2.2 后期采用DDD開(kāi)發(fā)模式來(lái)聚焦業(yè)務(wù)邏輯

使用DDD開(kāi)發(fā)模式來(lái)開(kāi)發(fā)和管理項(xiàng)目，作者帶領(lǐng)團(tuán)隊(duì)實(shí)踐了如下的過(guò)程。

1） DDD戰(zhàn)略設(shè)計(jì)

①將整個(gè)應(yīng)用程序域進(jìn)行劃分，剝離各個(gè)子域

在該項(xiàng)目中，經(jīng)過(guò)分析，作者共拆分出賬號(hào)管理、任務(wù)管理、積分管理、圖書管理等子域。

②對(duì)每個(gè)子域進(jìn)行限界上下文的設(shè)計(jì)

在每個(gè)限界上下文中，保證任何一個(gè)對(duì)象模型的語(yǔ)義是確定的、無(wú)歧義的。

比如在任務(wù)管理子域，定義一個(gè)User對(duì)象，作為任務(wù)創(chuàng)建人和執(zhí)行人存在，它就只具有與之相關(guān)的屬性和行為。而在賬號(hào)管理子域中，又定義了另一個(gè)User對(duì)象，它卻具有常見(jiàn)的用戶名、密碼、郵箱等屬性和對(duì)應(yīng)的行為。

雖然兩個(gè)User對(duì)象具有相同的名字，但是它們是完整的用戶對(duì)象在不同上下文中的投影，是兩個(gè)不同的對(duì)象。

在項(xiàng)目實(shí)施的過(guò)程中，作者選擇將子域和限界上下文一一對(duì)應(yīng)，獨(dú)立部署在每個(gè)AppService中。

2） DDD戰(zhàn)術(shù)設(shè)計(jì)

DDD戰(zhàn)術(shù)設(shè)計(jì)的核心就是把核心業(yè)務(wù)邏輯集中放到一起，組成領(lǐng)域?qū)?。其他層設(shè)計(jì)為依賴于該層。領(lǐng)域?qū)又邪兄匾念I(lǐng)域模型，包括聚合根、實(shí)體、值對(duì)象、領(lǐng)域事件、倉(cāng)儲(chǔ)、領(lǐng)域服務(wù)等。

①設(shè)計(jì)聚合根、實(shí)體和領(lǐng)域服務(wù)

在該項(xiàng)目的領(lǐng)域?qū)又校钪匾膶?duì)象就是聚合根和實(shí)體。它們完成了主要的業(yè)務(wù)邏輯。

使用聚合根還是實(shí)體，在實(shí)踐中一般都可以，但是如果完成一個(gè)業(yè)務(wù)操作，就一個(gè)主要的實(shí)體就可以了，不需要其他相關(guān)實(shí)體的配合，那么暴露這個(gè)實(shí)體給其他層就可以了。

比如Book這個(gè)實(shí)體，不僅包含了所有圖書的所有信息，還包括增加封面、修改作者、增加點(diǎn)評(píng)等各種業(yè)務(wù)行為。

但是如果完成一個(gè)業(yè)務(wù)操作，需要一個(gè)主要的實(shí)體，配合上其他一些相關(guān)的實(shí)體才能完成，那么就將主要的實(shí)體暴露成聚合根給其他層使用，把相關(guān)的其他實(shí)體全部隱藏起來(lái)，這些相關(guān)的實(shí)體的操作統(tǒng)統(tǒng)通過(guò)聚合根來(lái)暴露。

比如Task這個(gè)實(shí)體，不僅包含了所有Task自身的信息和操作，還包括其包含的子對(duì)象TaskItem實(shí)體的信息和各種操作，所以Task實(shí)體就暴露為聚合根，向外提供所有Task和TaskItem的相關(guān)操作，其他層無(wú)法直接操作TaskItem對(duì)象以及其方法。如圖6所示。

除此以外，還有一種情況就是，完成一個(gè)業(yè)務(wù)邏輯需要多個(gè)主要的實(shí)體配合，這個(gè)時(shí)候，就可以設(shè)計(jì)一個(gè)領(lǐng)域服務(wù)來(lái)實(shí)現(xiàn)這個(gè)業(yè)務(wù)邏輯，在這個(gè)領(lǐng)域服務(wù)中，它會(huì)使用其他相關(guān)的聚合根或?qū)嶓w來(lái)完成功能。

不過(guò)在該項(xiàng)目中，一般使用聚合的概念、暴露聚合根就可以實(shí)現(xiàn)需求了，需要使用領(lǐng)域服務(wù)的情況比較少，所以沒(méi)有用到。

②設(shè)計(jì)領(lǐng)域事件

該項(xiàng)目中，非常常見(jiàn)的一個(gè)需求就是一個(gè)實(shí)體改變了，需要通知其他的一些實(shí)體就行一些對(duì)應(yīng)的變化。這種需求就需要通過(guò)事件模式來(lái)實(shí)現(xiàn)。

在項(xiàng)目中，作者實(shí)現(xiàn)了一個(gè)EventBus作為通用的領(lǐng)域事件模型，任何實(shí)體都可以掛接這個(gè)對(duì)象，發(fā)布消息，或關(guān)注感興趣的消息并做出響應(yīng)，這個(gè)部分與通用的事件模型并沒(méi)有太大的不同，示意圖如圖7所示。

③設(shè)計(jì)倉(cāng)儲(chǔ)

使用倉(cāng)儲(chǔ)模式可以很好地隔離數(shù)據(jù)庫(kù)的操作和領(lǐng)域?qū)ο蟆?/p>

在領(lǐng)域?qū)?，作者定義了各個(gè)倉(cāng)儲(chǔ)接口，倉(cāng)儲(chǔ)與聚合根或?qū)嶓w一一對(duì)應(yīng)，包含對(duì)應(yīng)的增刪改查等操作，它們是數(shù)據(jù)庫(kù)操作的接口。

需要注意的是，在領(lǐng)域?qū)又?，只是定義了接口，并沒(méi)有具體的持久化的實(shí)現(xiàn)。具體的持久化工作放在了基礎(chǔ)設(shè)施層中。

3） 其他層的一些細(xì)節(jié)

①基礎(chǔ)設(shè)施層

這里重點(diǎn)說(shuō)明一下的是數(shù)據(jù)庫(kù)持久化的選型。

針對(duì)領(lǐng)域?qū)犹峁┑膫}(cāng)儲(chǔ)接口，作者實(shí)現(xiàn)時(shí)選擇了使用Entity Framework Core（以下簡(jiǎn)稱EF Core） 作為基礎(chǔ)框架。使用此類ORM框架大大簡(jiǎn)化了數(shù)據(jù)庫(kù)的操作，使用對(duì)象而不是SQL語(yǔ)句的方式可以避免很多語(yǔ)法上的錯(cuò)誤，有效地提升了代碼的健壯性。

而且使用了EF Core的Code First的方式后，項(xiàng)目只要使用EF Core的包命令就可以非常簡(jiǎn)單地根據(jù)實(shí)體對(duì)象的變更來(lái)創(chuàng)建和維護(hù)數(shù)據(jù)庫(kù)。

②應(yīng)用服務(wù)層

在該項(xiàng)目中，應(yīng)用服務(wù)層比較簡(jiǎn)單，它實(shí)現(xiàn)了一個(gè)公用的AppService，封裝了公用的分頁(yè)的邏輯。其他各項(xiàng)服務(wù)比如BookAppService都繼承自該基類，實(shí)現(xiàn)了自己的邏輯。

在各個(gè)服務(wù)中，為了調(diào)用領(lǐng)域?qū)拥臉I(yè)務(wù)邏輯，首先需要把前端傳過(guò)來(lái)的輸入數(shù)據(jù)傳輸對(duì)象（Data Transfer Object，以下簡(jiǎn)稱DTO） 轉(zhuǎn)換成領(lǐng)域?qū)拥臄?shù)據(jù)模型，然后調(diào)用領(lǐng)域?qū)拥念I(lǐng)域模型和基礎(chǔ)設(shè)施層的對(duì)象完成功能，最后再將結(jié)果轉(zhuǎn)換成輸出DTO返回給前端。

③后端接口層和前端表現(xiàn)層

接口層使用Restful Api去提供服務(wù)，前端表現(xiàn)層使用Vue 3.0實(shí)現(xiàn)展示，不管是否使用DDD，這些部分都是一樣的，不去多解釋。

經(jīng)過(guò)上述的分析、設(shè)計(jì)與重構(gòu)，最終得到如下新的架構(gòu)，如圖8所示。

3 結(jié)束語(yǔ)

采用了DDD來(lái)開(kāi)發(fā)和管理項(xiàng)目以后，項(xiàng)目的業(yè)務(wù)邏輯沉淀到了領(lǐng)域?qū)拥念I(lǐng)域?qū)ο笾校I(lǐng)域?qū)ο笞兂闪税瑯I(yè)務(wù)邏輯的充血模型，這樣業(yè)務(wù)邏輯得到了復(fù)用，程序的擴(kuò)展性得到了保證。

此外，由于存在清晰明確的分層和職責(zé)，團(tuán)隊(duì)日常的開(kāi)發(fā)效率得到了顯著的提升。目前該站點(diǎn)已經(jīng)上線并穩(wěn)定地運(yùn)行至今。

參考文獻(xiàn)：

[1] Fowler M.企業(yè)應(yīng)用架構(gòu)模式[M].北京：人民郵電出版社，2009.

[2] Evans E.領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)[M].北京：人民郵電出版社，2010.

[3] Vaughn V.實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)[M].滕云，譯.北京：電子工業(yè)出版社，2014.

[4] 歐創(chuàng)新，鄧頔.中臺(tái)架構(gòu)與實(shí)現(xiàn)：基于DDD和微服務(wù)[M].北京：機(jī)械工業(yè)出版社，2020.

[5] Richardson C.微服務(wù)架構(gòu)設(shè)計(jì)模式[M].喻勇，譯.北京：機(jī)械工業(yè)出版社，2019.

【通聯(lián)編輯：謝媛媛】

收稿日期：2022-01-25

作者簡(jiǎn)介：董向陽(yáng)（1982—） ，男，江蘇灌云縣人，中級(jí)工程師（上海） ，碩士，研究方向?yàn)橛?jì)算機(jī)應(yīng)用技術(shù)。