領域驅動設計模式的收益與挑戰:系統綜述?

賈子甲,鐘陳星,周世旗,榮國平,章 程

1(南京大學 軟件學院,江蘇 南京 210023)

2(計算機軟件新技術國家重點實驗室(南京大學),江蘇 南京 210023)

3(安徽大學 計算機科學與技術學院,安徽 合肥 230601)

領域驅動設計(domain-driven design,簡稱DDD)是一種在軟件設計中應該遵循的思維方式,其目標在于加快具有復雜需求的軟件項目的研發速度[1].DDD 中最重要的理念是通過構建領域模型來解決軟件開發的復雜性問題[1],因為在大多數軟件項目中,最困難的往往是解決業務領域復雜性,而非技術復雜性.DDD 的一個顯著特征就是設計與開發的綁定,DDD 強調軟件設計概念必須在開發過程中得以成功實現[2].為了實現以上這些愿景,在DDD 方法中,將一組設計實踐、技術和原則合并為標準模式,即所謂的領域驅動設計模式(domain driven design pattern,簡稱DDDP)[1],它們則構成了領域驅動設計的主體.

自從2004年“領域驅動設計”被首次提出以來[1],這一概念隨著軟件開發組織的廣泛應用逐漸流行起來.一些實踐者為DDD 社區做出了巨大的貢獻,例如:Nilsson[3]講述了如何通過結合DDD 來構建.NET 應用程序,Vernon[4]對于DDD 的概念給出了新的解釋,Millett 和Tune[5]闡釋了對DDD 的實踐、模式和原則的全面理解.同時,DDD 也被IBM[6]、阿里巴巴[7]等大型企業采用,以支撐大規模應用.此外,DDD 社區也活躍著多個面向工業界的會議,例如DDDSummit(https://ddd-summit.de),EXPLORE DDD(http://exploreddd.com)和DDDConference(http://www.ddd-china.com).

DDD 的立足點是解決軟件開發中的復雜性問題,這順應了當今軟件系統復雜度不斷提升的趨勢;此外,DDD 與當前主流的分布式架構設計風格——微服務架構(micro service architecture)[8]的關系非常緊密[9,10].而近年來,微服務架構已經越來越多地應用在各類大型軟件系統當中.上述技術特點和發展趨勢,使得DDD 在業界越來越流行.

然而,領域驅動設計也面臨著一些困境.在學術研究方面,相比于在業界實踐中的流行程度,DDD 相關的研究關注度明顯不足.在業界實踐方面,想要成功地在軟件開發中實踐領域驅動設計,特別是DDDP,往往具有一定的挑戰性.開發人員在應用限界上下文(bounded context)、聚合(aggregate)[4]等比較抽象的DDDP 時往往感到非常困惑,比如在分布式系統中應用限界上下文模式就存在一定困難[11],這在最近的一項微服務相關訪談研究[12]中得到了證實.

而DDDP 的實際應用情況如何?其能夠為軟件開發帶來何種收益?又將造成什么挑戰?上述問題目前尚未得到較為系統化的回答.因此,為了更加系統地了解DDDP 的應用現狀、收益、挑戰及相應的解決方法,本文進行了系統文獻綜述(systematic literature review,簡稱SLR)來調研已發表的基礎研究(primary study).系統文獻綜述是軟件工程領域的一種主要的“循證”方法,該方法通過合成當前研究中的高質量證據,以減少單個基礎研究的偏差,從而達到輔助軟件項目的決策過程的目的.自從這種“循證”方法被軟件工程社區采用以來,各領域的許多重要研究都應用了系統文獻綜述這一方法[13?15].考慮到軟件開發組織能夠從這種系統文獻綜述中獲取寶貴經驗,并且目前的學術界尚未發表有關領域驅動設計的綜述性文章,因此,本文的工作對于學術界和產業界均具有一定的借鑒意義.

具體而言,本研究工作的主要貢獻包括以下3 個方面:首先,本文揭示了DDDP 在軟件開發項目中的實際應用情況;其次,總結了應用DDDP 所帶來的收益,便于實踐者能夠在軟件項目中更好地把握機遇;再次,本文對于DDDP 應用實踐中所面臨的挑戰以及應對挑戰的緩解方法進行了論述,能夠幫助實踐者更好地應對挑戰,并為研究者提供了未來可能的探索方向.

本文第1 節介紹DDDP 的背景知識.第2 節介紹本文所采用的系統文獻綜述方法.第3 節給出綜述的結果.第4 節對于綜述結果進行深入分析和討論.第5 節分析本研究中存在的效度威脅.最后,第6 節給出對于應用DDDP 的總結與展望.

1 背景介紹

1.1 領域驅動設計的本質

領域模型(domain model)作為設計具有復雜業務規則的企業應用程序的一種軟件設計模式,該模式可以被看作是一個具有行為和數據的領域對象模型[16].領域模型正是領域驅動設計的基礎.具體而言,DDD 方法說明了如何利用DDDP 從業務中抽象出領域模型,并將其置于軟件開發的核心位置[1].

DDD 具有幾個基本原則.

?第一,在首先提出DDD 的書籍中[1],Evans 強調設計概念必須在代碼中成功實現,否則,它們將會變成抽象的討論.DDD 通過引入模型驅動設計(model driven design)建模范式及其構造塊,彌補了模型與可運行的軟件之間的差距;

?第二,DDD 還提倡迭代開發,并說明了如何借助敏捷[17]中的迭代式領域建模加速軟件開發[1].領域驅動設計與具體實現過程間的緊密關系,使得DDD 比其他軟件設計方法更具有實用性;

?第三,在實踐DDD 的過程中,開發人員和領域專家之間需要展開緊密協作,這是因為DDD 追求的領域模型需要依靠頭腦風暴的創造性和對領域的深入了解[1];

?第四,DDD 是一種軟件設計方法,而任何設計出來的領域模型都應該與架構無關[4].也就是說,除了領域模型,在軟件開發過程中仍然需要架構設計,比如微服務架構和六邊形架構[4].

1.2 領域驅動設計模式概覽

DDD 由Evans[1]作為一種大型模式語言(pattern language)引入,其由一組相互關聯的模式組成.模式語言提供了討論問題的交流術語,它定義了特定場景、特定問題的解決方案,其主要目的是幫助開發者解決在設計和編程中遇到的通用問題.模式語言在軟件工程中被廣泛地應用,比如設計模式(design pattern)、企業架構模式(enterprise architecture pattern)等.DDD 與DDDP 的關系,正如同面向對象設計(object-oriented design,簡稱OOD)與面向對象設計模式(即設計模式)的關系.

對于領域驅動設計而言,最基本的模式是通用語言(ubiquitous language),它是一種供不同涉眾(如開發人員和領域專家)共同使用的語言,主要用于輔助領域建模[4].一種通用語言只適用于單個限界上下文(bounded context),后者作為一個顯式的模型邊界來維護模型的完整性.根據Vernon[4]的觀點,除了通用語言之外的DDDP,要么屬于戰略設計模式(strategic design pattern),要么屬于戰術設計模式(tactical design pattern).

戰略設計模式旨在應對具有多個領域模型的大型軟件開發項目的復雜性,其中,每個領域模型都屬于單獨的限界上下文.具體而言,限界上下文作為一個顯式的模型邊界來維護模型的完整性,從而避免了模型之間的相互連接使彼此變得模糊[1].限界上下文以外的其他戰略設計模式關注如何管理不同限界上下文(如上下文映射和職責分層)之間的關系,比如,上下文映射(context map)負責描述不同領域模型間的通信,而職責分層(responsibility layer)則站在更高的抽象層級來組織不同領域模型間的概念依賴關系.

戰術設計模式負責根據通用語言對單個限界上下文進行領域建模[4],并結合面向對象的原則來綁定領域建模和編碼實現.戰術建模的典型模式包括實體(entity)、值對象(value object)、聚合(aggregate)、服務(service)、資源庫(repository)等.具體來講:實體和值對象用于對具有不同領域特征的領域對象進行建模;聚合將一組領域對象綁定為一個整體,以控制事務;服務則充當領域模型的接口,具有無狀態的特點;而資源庫則用于封裝領域對象的數據庫訪問操作.

2 綜述方法

本系統性文獻綜述根據Kitchenham 等人的指南[18]開展研究.本節首先提出驅動本工作開展的研究問題,其次描述了數據收集所遵循的詳細策略和流程,最后描述了本研究的數據抽取和合成過程.

2.1 研究問題

本研究的總體目標是形成在軟件開發中應用領域驅動設計模式的系統性理解,了解應用領域驅動設計模式的實踐情況,包括其帶來的收益、挑戰及應對挑戰的緩解方法.為此,本研究提出了如表1所示的具體研究問題.其中:研究問題1 是為了了解DDDP 在軟件開發項目中的應用現狀;研究問題2 是為了調研應用DDDP 所帶來的收益情況;研究問題3 是為了總結應用DDDP 所面對的挑戰以及應對挑戰的緩解方法,并挖掘未來可能的研究方向.

2.2 文獻收集

本小節描述了系統文獻綜述中的數據收集過程,包括了文獻檢索、文獻篩選、文獻整合、滾雪球、質量評估和模式識別等.文獻收集的總體流程(于2019年7月進行)如圖1所示.本文的3 位作者在來自手動檢索、自動檢索以及滾雪球過程的1 884 篇文獻中最終確定了26 篇高質量的基礎研究(primary study)作為研究集合.

Fig.1 Literaturecollection procedure圖1 文獻收集過程

2.2.1 文獻檢索

為了盡量降低遺漏任何相關文獻的風險,本文采用了多種文獻檢索策略.此外,根據Kitchenham 等人的指導方針[18],我們通過試點(pilot)文獻綜述確定了一組相關文獻,以用于驗證檢索過程的完整性.這組已知文獻包括:

?Challenges of domain-driven microservice design:A model-driven perspective[J];

?Towards a UML profile for domain-driven design of microservice architectures[C];

?Designing microservice-based applications by using a domain-driven design approach[J];

?An ontology-based approach for domain-driven design of microservice architectures[J].

接下來對檢索過程的一些關鍵步驟進行詳細說明.

(1)手動檢索

為了提供更全面的自動檢索字符串,本研究首先進行了手動檢索.本過程所選取的兩種出版源分別是:

①已知文獻集合的出版源;

②軟件設計和架構相關的期刊與會議.

手動檢索的過程首先由本文的兩位作者獨立進行,之后將檢索結果合并到一起,即:只要一位作者認為該文獻與本研究相關,就會被納入此階段的文獻集合中.

表2 展示了從各個出版源檢索到的相關文獻數量.

Table 2 Publication venues included in manual search表2 手動檢索的出版源

(2)自動檢索

在這一階段,本文作者檢索了3 個主要的在線學術數字圖書館:①IEEE Xplore(https://ieeexplore.ieee.org/Xplore);②ACM Digital Library(https://dl.acm.org);和③ScienceDirect(https://www.sciencedirect.com);以及一個索引系統:④Scopus(https://www.scopus.com).對于檢索字符串,本文作者確定了研究問題中最普遍的關鍵字(即“DDD”),并決定只包含它和它的相關同義詞進行檢索,這些同義詞是從手動檢索結果和已知的論文集合中獲得的.通過合并OR 操作符,本文使用的最終檢索字符串如下:

(“DDD” OR “domain driven design*” OR “domain-driven design*” OR “domain driven approach*” OR“domain-driven approach*” OR “domain driven develop*” OR “domain-driven develop*”)

每個檢索源的詳細檢索結果見表3.

Table 3 Intermediate result in snowballing表3 滾雪球過程的中間結果

(3)滾雪球

在手動檢索與自動檢索之后,本研究中還使用了反向滾雪球(backward snowballing,簡稱BSB)和前向滾雪球(forward snowballing,簡稱FSB)方法對檢索結果進行補充.考慮到滾雪球的初始論文集決定了該過程的效率和完整性,本研究將手動檢索和自動檢索所得進行文獻選擇并合并后的結果(見圖1 和表4)作為滾雪球的初始集合.注意,所有手動檢索的結果都被自動檢索的結果覆蓋.在這個階段,我們遵循Wohlin[19]的指導方法,并且反復迭代滾雪球的過程,直到不再有新的文獻被發現.

表4 中,第1 次迭代和第2 次迭代最終分別獲得16 項(5+12=17,其中1 篇文獻重復,最終得到16)和2 項新研究文獻.

Table 4 Intermediate result in snowballing表4 滾雪球過程的中間結果

(4)DDDP 的自動檢索

為了進一步確保研究集合的完整性,本研究通過基于DDDP 名稱的自動檢索來補充現有的檢索策略.具體來說,我們在Scopus 中執行了另一個自動檢索過程,其檢索的字符串由每個模式的名稱以及“domain”(“領域驅動設計”的最通用術語)和“software”(軟件工程最通用的術語)組成.比如,與DDDP“Entity”(及“Entities”)相關的檢索字符串為如下:

(“Entit*” AND “domain” AND “software”).

對于DDDP 的完整列表,我們遵循了Evans[20]在2014年的總結,總共包含45 個模式.然而,雖然這種檢索方法使用Scopus 中的字段碼TITLE-ABS-KEY 檢索到了7 515 篇論文,但經過文獻篩選后,并未獲得新的文獻.兩次檢索所得論文數量的巨大反差,可能是因為許多DDDP 的名稱在軟件工程中也非常通用,比如服務(service)和資源庫(repository)等.因此,本文并沒有在圖1 中包含此檢索過程.

2.2.2 文獻篩選

本系統文獻綜述使用的文獻納入和排除標準如下所示.注意,只有符合所有納入標準的基礎研究文獻才會被納入,而符合任何一項排除標準的文獻都將被排除.

(1)納入標準(include criteria)

?IC1:文獻提供了關于DDD 的某種形式的數據.在這一階段,我們的目標是最大限度地擴大文獻范圍,以確保研究的完整性;

(2)排除標準(exclude criteria)

?EC1:發表于2003年DDD 被發表之前的文獻(因為DDD 于2003年被提出);

?EC2:無法獲得電子版全文的文獻;

?EC3:用英語以外的語言撰寫的文獻;

?EC4:沒有經過同行評審的文獻;

?EC5:存在更加完整的文獻.即同一基礎研究(primary study)有多篇文獻,此時將最完整的文獻納入.

具體篩選過程如下:

?前期準備:按主題篩選——我們通過瀏覽自動檢索得到的每篇文獻的標題,并確定其是否屬于軟件工程領域.注意,這個階段是專門為自動檢索設計的,因為一些數字圖書館(例如Scopus 和ScienceDirect)不支持基于主題的篩選,或者其基于主題的篩選功能相對有限;

?第1 階段:按標題篩選——我們通過瀏覽手動檢索、自動檢索以及滾雪球所得到的文獻列表的標題,以確定哪些文獻符合納入/排除標準;

?第2 階段:按關鍵詞和摘要篩選——我們分析通過第1 階段的文獻的關鍵詞和摘要,進一步確定它們是否符合選擇標準;

?第3 階段:閱讀全文篩選——我們通讀了通過前兩個階段的文獻全文,并保留符合預先定義的篩選標準的文獻.

表5 給出了篩選過程的中間結果.

Table 5 Selection details of literaturefrom different search methods.表5 不同檢索階段的文獻選擇情況

在分配選擇任務時,我們確保每篇文獻的每個選擇階段都由至少兩位作者完成.此外,每篇存在爭議的文獻都要先由第三位作者進行評估,然后再通過討論達成共識.如果這樣還無法解決分歧,則將會和本研究的指導者進行討論,直到達成共識為止.此外,為了增強我們對文獻篩選過程的信心,本研究在自動檢索所得文獻的篩選過程中引入了Kappa 評分[21],并且最終Kappa 評分結果為0.722(“Good/Substantial”).另外,還有兩項證據也可以證明檢索和篩選過程的全面性.

?所有已知集合中的文獻(來自試點文獻綜述)都可以通過檢索過程找到,并且被選中;

?從手動檢索中選取的所有文獻都包含在自動檢索的選擇結果中.

2.2.3 質量評估與模式識別

在研究集合的確定過程中,本工作還引入了質量評估(quality assessment)來排除一些質量較低的基礎研究.根據Dyba 等人[22]的質量檢查表,本研究制定了質量評估標準,該標準通過了本研究指導者的審查.在質量評估過程中,我們根據評分情況排除了共15 篇質量得分較低的基礎研究.

在經過質量評估之后,本研究進行了模式識別,進一步排除了沒有提及任何DDDP 的基礎研究(圖1).之所以將模式識別作為一個環節而不是一項文獻篩選標準,是因為一些目標文獻可能在另一些文獻的滾雪球階段被納入進來,而后者可能并沒有提及任何DDDP 而只與領域驅動設計理論相關.這樣做的目的是在收集文獻時盡可能全面地覆蓋相關文獻.我們排除了手動檢索和自動檢索中的11 篇論文以及滾雪球檢索中的1 篇論文,最終得到了26 篇高質量基礎研究.

2.3 數據抽取與合成

首先給出指導數據抽取過程的數據抽取項,然后描述對數據抽取結果的合成(synthesis)方法.在數據抽取和合成環節中,我們主要使用Nvivo(https://www.qsrinternational.com/nvivo)和電子表格來記錄數據.

2.3.1 數據抽取

我們參照Zhang 和Budgen[23]的方法定義了數據抽取項(見表6),其主要由基礎信息、研究背景以及研究問題相關信息這3 部分組成.其中:基礎信息指的是文獻的標題、作者以及發表時間等內容;研究背景指的是文獻的研究興趣特征,這些信息可能會影響結果的解釋方式;研究問題相關信息指的是文獻中與DDDP 相關的知識,包括回答研究問題所需要的數據項.除了描述每個數據抽取項之外,表6 還說明了本研究是否為這些數據抽取項提供特定的代碼,如果代碼為“否”,則該抽取項使用自由文本進行提取.為了進一步確保數據抽取表的可靠性,本文作者與指導者一起對其進行了審查,并且隨機選擇了3 篇文獻進行了試點研究(pilot study),并根據實驗結果對數據抽取項進行了改進.

在進行數據抽取時:首先,我們使用格式化的電子表格來統一數據抽取格式;然后,兩位作者逐字逐句地閱讀文獻并抽取相應的數據.在此過程中,來自研究文獻的原始文本被原封不動地記錄到數據抽取項中.此外,正如Cruzes 和Dyba[24]所推薦的,我們也將表格和圖形作為數據抽取的素材粘貼到電子表格中.

Table 6 Data extraction items表6 數據抽取項

2.3.2 數據合成方法

為了深入了解DDDP,本研究的數據抽取過程產生了大量的定性數據.此外,在DDDP 相關的基礎研究中,同一個詞語在不同的上下文中可能具有不同的含義,比如“服務(service)”可能表示一種DDDP,但也可能表示軟件工程中非常普遍的“Web 服務”[25],這為數據合成造成了一定阻礙.因此,本研究需要使用一種合適的定性數據合成方法,來保證能夠合成出語義合適的結果.

本研究在進行定性數據合成的過程中,使用了來源于扎根理論(grounded theory)[26]的兩個抽象層次的編碼方法,即開放碼(open codes)和軸向碼(axial codes)[27].本研究所使用的編碼方法是Braun 和Clarke[28]提出的主題分析(thematic analysis),我們利用該方法獲得了各種定性數據(見表6)的聚合結果.

這里簡單介紹數據合成過程的一些細節.在熟悉了基礎研究文獻之后,兩位作者分別對提取到的原始文本進行開放編碼,即識別文本的語義內容和隱含內容,并將其與原始數據一起記錄下來.例如,示例抽取數據的開放編碼結果是“更好地理解領域需求”和“更有效的溝通”.當所有的數據集都完成了初始編碼后,我們對不同的代碼進行分析和比較,并將它們組合成主題.例如,開放編碼“更好地理解領域需求”被整理成主題“促進業務理解”.之后,我們進一步對于候選主題進行了細化,比如因為證據不足而放棄了某些開放編碼.在這個過程中,NVivo 被用來管理編碼和主題之間的層次結構.此外,考慮到這一過程極大地依賴于經驗和感知,在執行這一階段工作之前,所有數據分析和合成的參與者都被要求仔細研讀DDD 相關的主流著作[1,3,4,20,29].

3 研究結果

領域驅動設計模式的應用最終表現在一系列相關活動中,因此,本研究識別出了應用DDDP 的相關活動,并以此為基礎來組織應用DDDP 所帶來的收益與挑戰.如圖2所示,根據基礎研究[30],應用DDDP 的相關活動主要分為4 類,即領域分析(domain analysis)、領域設計(domain design)、領域模型實現(domain model implementation)和普適性活動(umbrella activity),由此組成了DDDP 應用框架,并且上述這些活動與Bruegge 和Dutoit[31]所描述的傳統軟件開發活動,即需求獲取和分析、設計和實現及測試相對應.

對于DDDP 應用框架的進一步說明如下.

?領域分析是指與領域專家一起探索領域知識的過程.經過領域分析,將得到初始的領域模型;

?領域設計是指將模型分成不同部分(每個部分對應著獨立的限界上下文),然后擴展和細化每個限界上下文的過程,以此為開發實現做準備;

?領域模型實現是指將模型轉換為可運行代碼,這一過程還通過檢查模型為模型設計提供反饋;

?普適性活動指的是應用DDDP 時,可能在領域分析、領域設計、領域模型實現這3 個階段都會發生的橫切活動,比如構建和更新通用語言.

值得一提的是:在這些活動中,開發團隊可能對領域產生更深刻的洞察,并變更之前所做的設計決策.

Fig.2 An overview of activities in applying DDD patterns圖2 應用DDDP 的活動概覽

3.1 研究文獻的總體情況

經過收集,本研究總共獲得了26 項基礎研究,本部分將簡要介紹這些相關研究的總體情況.

?出版年份

圖3 顯示了所收集的文獻按出版年份的分布情況.統計數據顯示:2006年之前,社區中沒有發表過DDDP 相關的基礎研究文獻;而在2006年~2015年期間,文獻發表數量一直保持在較低的水平(每年不超過2 篇).這說明自2003年以來,領域驅動設計及其模式在最初的十幾年里并沒有得到研究者的足夠重視.然而2016年之后,該領域的論文發表數量逐年增加,這可能與DDD 和微服務架構在2016年的結合有關,特別是在QCon 倫敦2016年大會上[32],《Domain driven design:Tackling complexity in the heart of software》的作者Eric Evans 提出使用領域驅動設計概念能夠減少微服務環境中通用語言(一種DDDP)的復雜性.本次大會上,Evans 還介紹了3 種可以幫助管理微服務的DDD 工具,并建議將每個微服務設計成一個限界上下文(一種DDDP).DDD 與微服務結合,使得該領域的研究與應用變得更加活躍,這可能是2016年后相關文獻數量持續增長的一個重要原因.

Fig.3 Distribution of literatures by years圖3 文獻發表年份分布

?作者來源

圖4 顯示了所收集的文獻按作者來源的分布情況.根據對于論文署名作者及其所屬機構的統計數據顯示:在本工作所選取的26 篇基礎研究文獻中,69.2%(18/26)的文獻的全部作者均來自于學術界(包括高等院校以及科研機構等);但是與此同時,也有26.9%(7/26)的文獻作者均來自于業界;此外,還有1 篇文獻由來自于學術界和業界的多位作者共同完成.綜上所述,在本文所選取的DDDP 相關基礎研究中,大約30.8%的研究工作有業界的參與,這也從側面印證了DDD 在軟件開發業界的流行程度.

Fig.4 Distribution of literatures by authorship圖4 文獻作者來源分布

?研究形式

圖5 顯示了不同研究形式的分布情況.其中,61.5%(16/26)的文獻屬于案例研究(case study),當研究對象之間的聯系復雜且重要時[18],案例研究是一種非常合適的研究形式.同時,在所有相關研究中,實驗都不是主要方法.這可能是由于根據Easterbrook 等人的理論[33],控制實驗不適合真正復雜的軟件項目.此外,23.0%(6/26)的文獻采用了經驗報告(experience report)的形式,這種形式能夠幫助讀者從中獲得實際經驗,因此也非常受歡迎.

Fig.5 Distribution of literatures bystudy form圖5 文獻研究類型分布

?貢獻類型

如圖6所示,大多數研究(18/26,69.2%)提出了DDD 相關的解決方案.這些解決方案研究的目的可以分為兩類,其中,77.8%(14/18)的文獻致力于利用DDD 解決具體軟件系統的開發問題,22.2%(4/18)文獻試圖解決DDD應用的局限或挑戰.此外,15.4%(4/26)的文獻論述了將DDD 應用于實踐中所獲得的經驗和教訓.

Fig.6 Distribution of literaturesbycontribution type圖6 文獻貢獻類型分布

3.2 DDDP的應用情況(RQ1)

表7 總結了在基礎研究集合中,出現頻次到達3 次以上的DDDP,以及對應的描述和提及這些模式的研究文獻.顯然,這些模式出現的頻次并不平衡.其中,戰術設計模式被提及的頻次明顯高于戰略設計,這與Millett 和Tune[5]的發現基本一致,即,開發人員更容易注意到領域驅動設計的戰術設計模式.總體而言,目前只有31.1%(14/45)的DDDP 在基礎研究中得到了探討,這也表明了當前學術界對DDDP 的研究存在不足.

Table 7 Distribution of DDD patterns in literatures表7 研究文獻中DDDP 的分布情況

作為一種模式語言,DDD 由一組相互關聯的模式組成(即DDDP).Vernon[4]指出:如果在實踐中忽略通用語言和DDD 戰略設計,而僅僅使用部分戰術設計模式,就可能導致領域概念之間的緊密耦合,這樣的問題被稱為“DDD-Lite 陷阱”.本研究發現:在研究集合中,僅有文獻[30,41,42]明確地應用了通用語言、戰略設計模式和戰術設計模式.有2 項研究可能落入了DDD-Lite 陷阱,因為它們只展示了戰術模型,而沒有提出任何與戰略層面實踐相關的觀點.比如文獻[35]在文章中論述了他們如何演進通用語言、戰術領域模型以及持久化策略等實現細節,而并沒提及戰略設計.與此同時,5 篇研究文獻在研究中只采用了戰略設計,而沒有關注戰術設計.具體而言,這些研究專注于企業架構層面,主要分析如何利用戰略模式(如限界上下文和上下文映射等)來組織具有多個領域模型的大規模結構.此外,基礎研究[40]較為特別,它既沒有論述戰略設計,也沒有論述戰術設計,而是分析了如何通過映射具有相似語義的領域概念,將兩種不同的戰術領域模型集成到一起.

3.3 應用DDDP所帶來的收益(RQ2)

為了便于讀者理解,本文以表格形式展現了將DDDP 應用到DDD 活動中的收益與挑戰.表8 展示了應用DDDP 所帶來的收益在領域分析、領域模型實現以及普適性活動中的體現情況,并展示了相關模式和研究文獻的證據覆蓋范圍.除領域分析之外,本研究在DDD 活動的各個階段均發現了應用DDDP 所帶來的收益.

Table 8 Benefits of applying DDD Patterns表8 應用DDDP 所帶來的收益

值得注意的是:一些研究文獻所提到的顯著收益可能來自于其對于多種DDDP 的綜合作用,而不是某一種DDDP 的作用.接下來,本文將分階段討論應用DDDP 所帶來收益的細節.

3.3.1 領域設計

在領域設計中,應用DDDP 的收益在于能夠使各個領域之間的依賴關系更加明確(B1).上下文映射(context map)和職責分層(responsibility layer)用于組織系統的不同部分:前者表示不同限界上下文之間的關系,每個上下文表示一個特定的領域;后者則根據領域對象的職責,將它們組織成具有清晰依賴關系的層次結構.借助這些DDDP,我們能夠清晰地認識領域之間的關系和依賴.本質上,正如基礎研究[53]所宣稱的,我們可以利用這些模式了解功能之間的依賴關系.因此在確定系統邊界時,不同領域的戰術設計知識以及領域之間的關聯關系將變得更加明確.理清領域之間的依賴關系還可以幫助開發人員更加深入地了解系統,降低認知復雜性[52],有助于分析系統架構.

3.3.2 領域模型實現

應用DDDP 有助于領域模型的落地實現.比如應用資源庫(repository)和工廠(factory)模式分別可以將存儲和初始化的復雜邏輯從領域模型中剝離出來[37,39],因此能夠改善軟件開發的效率,使得開發人員能夠在存儲和初始化的不同實現方案之間的更加輕松地進行切換(B2).一方面,借助資源庫模式,當需要更改系統時,往往只需要更改相關的代碼實現,而不必去檢查整個對象模型[37];另一方面,工廠模式隱藏了復雜的初始化邏輯,因此可以在不引用具體實現的情況下輕松地切換實現方式[39].

當涉及到限界上下文之間的通信時,防腐層(anticorruption layer)封裝了兩個上下文之間領域概念的轉換,從而避免一個上下文過多地掌握另一上下文的知識.正如基礎研究[55]所指出的:通過將領域模型從執行與其他系統相關的任務中解放出來,防腐層允許實踐者在不改變領域模型的情況下集成外部系統,從而減少系統集成的開銷(B3),這對于需要與遺留系統或第三方系統進行集成的應用程序至關重要.此外,開放主機服務(open-host service)通過一組服務提供了對限界上下文的訪問[1],即,將這些服務發布為設計構件.這樣一來,接口的重用性(B4)和松耦合得到了極大改善.

讓代碼意圖更明確(B5),也是應用DDDP 帶來的一個顯著收益.DDD 強調對于模型和實現的綁定,所以在編寫代碼時需要使用與領域建模過程相同的術語[37],也就是通用語言.這樣一來,由于整個團隊將通用語言作為相互溝通的基礎,能夠使代碼的業務邏輯將變得更加清晰[37].與此同時,借助于通用語言這種模式,不同涉眾之間可以直接基于代碼而不是海量的文檔進行信息交換,這使得團隊的溝通、協作效率大大提升.

3.3.3 普適性活動

應用DDDP 可以提升軟件架構的質量屬性(B6),如可維護性、可擴展性、可重用性和可測試性等.這一觀點在現有研究文獻中被廣泛認可.首先,限界上下文和上下文映射將一個復雜的領域分解為幾個部分,幫助系統實現模塊化.文獻[52]的經驗表明:實現上下文映射可以幫助開發人員對系統產生更深刻的認識,從而進一步改進系統架構;其次,識別和關注核心域(core domain)可以提高資源利用率,從而以更高效的方式改善軟件架構;再次,分層架構(layered architecture)能夠將領域模型與其他關注點分離開來,有助于探索領域知識,也有助于確保各層之間的高內聚和低耦合[54].

由于DDDP 中的通用語言能夠作為團隊內部的共享術語來降低溝通中的噪聲,所以在設計領域模型和分析代碼的過程中,通用語言能夠為不同的涉眾提供高效的通信方式(B7).正是因此,領域專家的參與度得以大大提升,使得更多高價值的領域業務見解在團隊內部分享和傳遞.更好地理解業務(B8)能夠使得軟件與其所在的領域保持一致,這也正是領域驅動設計的基本觀點[4,29].另一方面,對于領域模型特別是核心域的關注,使開發人員能夠更好地理解正在開發的軟件和其未來愿景,有助于架構決策的制定,如開發資源的高效利用(B10)和系統級優化.

最后,應用DDDP 能夠幫助復雜軟件架構以更加敏捷的方式實現演進(B9),并且能夠幫助團隊應對具有較大領域復雜性的軟件系統開發難題(B11).

3.4 應用DDDP所面對的挑戰(RQ3)

總結現有研究中對于應用DDDP 所帶來的挑戰,能夠為學術界提供一些未來的研究方向.然而對于實踐者而言,其往往更關心應對挑戰的策略和方法.盡管我們難以在現有研究中找到應對DDDP 所帶來挑戰的“銀彈”,但研究文獻中所提出的一些方法,卻能夠幫助實踐者在一定程度上緩解應對挑戰的難度,我們將其稱為挑戰的緩解方法.在本研究中,我們首先在基礎研究中提取了應用DDDP 的17 個挑戰,之后,3 位研究者根據所得到的挑戰列表和系統文獻綜述過程所收集的證據,獨立抽取并合成應對挑戰的緩解方法,經過分析、討論與整合,最終得到了17 個應對挑戰的緩解方法.

表9 列出了在領域分析、領域設計、領域模型實現和普適性活動這些活動中,應用DDDP 可能面臨的挑戰以及相應的緩解方法.接下來,本文將分階段對其進行詳細介紹.

Table 9 Challenges of applying DDD Patterns表9 應用DDDP 所需要面對的挑戰

Table 9 Challenges of applying DDD patterns(Continued)表9 應用DDDP 所需要面對的挑戰(續)

3.4.1 領域分析

在領域分析部分,本文發現了一種應用DDDP 的挑戰(C1),但是并沒有在研究文獻中找到能夠緩解該挑戰的方法,因此在本部分的緩解方法中,本文根據經驗總結出了兩條應對建議.

?挑戰

領域驅動設計及模式致力于幫助開發組織深入理解軟件的業務領域,以便在系統開發中充分發揮創造力[39].為了更加深入地了解相關領域,無論是形成統一語言還是確定限界上下文和核心域,都強調領域專家與開發人員之間的緊密協作.然而,讓領域專家參與領域驅動設計實踐并非易事(C1),這成為了阻礙DDDP 成功應用的一個主要障礙,特別是在所開發的軟件系統非常復雜,需要不同領域的多個領域專家共同參與的情況下.Vernon[4]也認同了這一觀點,他認為:讓領域專家參與軟件開發過程,一直以來都十分困難.

?緩解方法

在本研究所搜集的基礎研究文獻中,并沒有針對領域分析階段所遇到的C1 提出任何解決方案.顯然,C1 更像是一個組織問題,而不是技術問題.結合Vernon[4]的觀點,我們為應對C1 提供了兩條建議:①如果軟件開發組織決定應用領域驅動設計,那么就應該充分認識領域專家的重要性;②領域專家指的不是一個職位,而指的是非常了解業務線的人,因此,領域專家可能是銷售人員,也可能是產品設計師[4].

3.4.2 領域設計

在領域設計部分,本文發現了8 種應用DDDP 所帶來的挑戰(即C2~C9),并且對于其中除了C3,C4 和C7 之外的5 項挑戰都發現了一些對應的緩解方法(M1~M12).

?挑戰

通過引入限界上下文模式,可以將復雜軟件系統拆分為不同部分,拆分后的每個部分都可以獨立建立具有清晰邊界的領域模型.正如Newman[8]所建議的:借助限界上下文將相關業務功能組合為業務能力,以此來確定微服務粒度.這一方法已被軟件開發社區廣泛接受[51].然而對于限界上下文本身的粒度,DDD 并沒有提供任何有助于實現高內聚、低耦合(C2)的指導方法.近期的一項相關研究[59]證實了這一挑戰,該工作宣稱:使用限界上下文對軟件系統進行拆分是非常困難的,因為不同業務功能之間的界限通常并不明顯.

將一個領域拆分為多個子域之后,應首先識別出系統中最具決定性的子域,即核心域,并側重對核心域的投入,以實現收益最大化[4].但在實際中,對開發人員而言,識別系統的核心域往往非常困難(C3),尤其是在開發大型系統時.此外,基礎研究[52]還發現,在實踐中可能會同時存在多個核心域,因此進一步加劇了這一挑戰.

在每個限界上下文內應用戰術設計模式主要面臨兩個挑戰:其一,確定聚合的粒度非常困難(C4),這需要在執行單個事務的成本和強一致性兩者之間取得平衡[58];其二,使用分層架構(layered architecture)將領域模型與其他模塊進行對應時,DDDP 中并未對領域層之外的其他層,如用戶界面層、應用程序層和基礎設施層等,提供任何相關規范(C5)[1].本質上講,領域驅動設計強調使用領域模型來展示領域的功能視圖,但并沒有考慮其他方面[30].然而,這種對領域層之外規范的缺失,將會為實踐者帶來一定的困擾.

在模型中表達領域知識時,Evans[1]強調可以利用各種媒介進行溝通(不僅是UML[31])來最大化模型表達的效率.但這就帶來了另一項挑戰,即,領域驅動設計缺乏對模型的形式化表達的支持(C6).文獻[44]指出:DDD 的定義不僅缺少形式化基礎,還在某些情況下具有不同的表達方式.在應用微服務架構構建應用程序時,領域模型將分散在不同團隊中,因此具有相同語義的領域對象可能會在不同團隊中獨立演變,從而變得完全不同.這樣一來,很可能使得不同團隊對相同的領域概念產生不同的理解[47].

在基礎研究文獻中還提到了其他的一些挑戰,如基礎研究[46]所描述的,領域模型的建模過程需要領域專家的參與,但卻無法保證領域專家能夠理解建模過程中使用的全部技術(C7),這對于通用語言的實踐造成了一定困難.此外,當前的建模工具還不能完全適用于領域驅動設計(C8).最后一點,雖然DDD 提供了多種模式,但是領域模型的復雜度依然會影響模型本身的可理解性(C9).

?緩解方法

為了確定限界上下文的合理粒度(C2),多個研究文獻給出了相關建議.首先,文獻[30,44]認為,應該考慮團隊的組織結構.其次,文獻[41]建議找到職責的邊界,并將其作為該領域的業務功能.文獻[49]建議通過分析用例的工作流將相關功能聚集在一起,并將其劃分為不同的領域,也就是限界上下文;此外,通過將領域專家和開發人員召集在一起來討論業務領域的事件風暴[60],也是一種行之有效的重要手段.通常而言,限界上下文往往需要經過多次迭代才能夠最終確定,根據文獻[42]的經驗,比較來自于不同團隊的領域模型,有利于使領域邊界更清晰.

為了應對微服務場景中的C5,也就是領域驅動設計在其他層中沒有提供任何規范這一挑戰,需要添加其他工件來彌補規范的缺失[30].根據Fairbanks[61]的建議,在決定向系統中增加新的工件時,需要仔細考慮項目中存在的風險.例如:當使用DDD 構建基于微服務的Web 應用程序時,文獻[30]根據用戶體驗設計的指導原則來定義用戶界面和交互,根據行為驅動開發(behavior-driven development)來確定應用層的需求,并使用Spring 框架搭建基礎設施層.

為了使建模語言更加形式化(C6),基于在領域驅動設計中應用UML 元素情況的調研,文獻[44]定義了一種用于建模的UML 配置文件(profile),并充分考慮到了各元素的語法和語義.應用這種UML 配置文件的案例表明,其能夠將基于這種配置建模的領域模型映射到微服務中.文獻[48]的研究工作進一步驗證了這種UML 配置文件的有效性.除此之外,本體論是一種在特定領域中描述語義的方法,其能夠對系統結構進行形式化建模,比如實體和關系等[62].基于本體論,基礎研究[47]提出了一種表達領域模型語義及關系的元模型,以此來確保整個團隊對分布式領域驅動微服務設計中的相關領域概念具有相同的理解.

對于建模工具(C8)而言,文獻[44]在Eclipse 和Papyrus 建模環境的基礎上實現了UML 配置文件;文獻[56]在Eclipse 平臺上開發了Elihu 項目,能夠對于領域對象相關的應用功能進行建模,而無需考慮基礎設施方面的問題.此外,文獻[48]建議使用另一個基于Eclipse 的工具——AjiL 來實現微服務的圖形化建模.AjiL 能夠通過建模得到初步的領域模型,并通過代碼生成器將模型轉化為微服務的具體實現.

對于模型復雜度(C9)而言,概念架構視圖[9]被引入并用于將模型拆分為多個領域視圖.這樣一來,建模者能夠從不同視圖進行領域建模,而其中每個視圖都代表了特定涉眾的觀點.

3.4.3 領域模型實現

在領域模型實現部分,本文發現了5 種應用DDDP 的挑戰(即C10~C14),并且對于其中的C12 和C13 尋找到了對應的緩解方法(M13,M14).

?挑戰

本研究發現:在領域模型的實現過程中,防腐層(anticorruption layer)與服務(service)的實現復雜度較高(對應C10 與C11).對前者而言,文獻[41]提到,實現防腐層的最大挑戰在于控制轉換復雜度,也就是開發人員必須充分理解兩個限界上下文及其關聯;而對后者而言,文獻[43]指出,應確定服務的粒度來確保能夠提供合理的對相關領域的訪問.由于DDD 主要關注領域模型,并沒有對服務實現給出詳細指導,因此為實現過程造成了一定的困難.

此外,由于DDD 側重于業務領域而非技術領域,這也帶來了兩項挑戰.

?第一,DDD 中的領域模型沒有指定后續的實現規范(C12).舉例而言,領域對象的屬性可能是無類型的,或者缺少具體的行為方法[48].但是這類信息對于后續實現而言往往是必要的,而由于這類信息的缺失,使得從模型清晰地推斷出技術特性變得非常困難;

?第二,領域模型并不包含基礎組件或部署視圖中的基礎設施(C13),但這類視圖或組件信息有時會在很大程度上影響軟件系統,特別是在微服務場景中.因此,這類信息需要使用文檔加以記錄來作為對模型的補充.

模型驅動開發(model-driven development)能夠提高領域模型到代碼轉化的效率,在DDD 中得到了較廣泛的應用.然而,即使在將領域模型正確轉換為代碼之后,由于領域建模過程的不斷迭代,仍然有可能需要重復這一過程.因此,模型到代碼轉換的自動化(C14)十分必要.而為了使得模型與代碼始終保持一致,則需要在建模的每個迭代過程中持續地關注各個領域元素[1].盡管在DDD 中引入了模型驅動設計,但如何在模型的細化過程中保證代碼和模型的一致性[44],仍然是一個難題.

?緩解方法

建模規約(convention)[48]意味著為建模過程設置需要遵守的規則.建模規約通過為領域模型賦予更多形式化內容,來應對DDD 中領域模型缺乏實現規范的挑戰(C12).文獻[48]中提供了一些規則示例,比如在建模時禁止雙向關聯、事先規定引入微服務接口的DDDP 等.針對領域模型中缺少基礎組件的情況(C13),文獻[48]建議利用來自模型驅動開發[63]的中間模型來表示技術特性,如接口模型和部署模型等.前者用于對服務接口進行建模,后者用于對可部署工件進行建模.這些中間模型能夠展示特定角度的技術特性,有助于接口類型和部署技術的進一步實現.

3.4.4 普適性活動

在普適性活動部分,本文發現了3 種應用DDDP 的挑戰(即C15~C17),并且對于其中的每個挑戰尋找到了對應的緩解方法(M15~M17).

?挑戰

文獻[37]提到:在形成通用語言的過程中,由于不同涉眾使用的語言不同,往往難以對于同一術語形成統一認識(C15).這使得團隊在溝通過程中可能會產生誤解,想要定義通用語言往往需要付出更多的努力.

領域模型的獲取與變更管理,是應用DDDP 的另一項挑戰.Vernon[4]建議由單個團隊來開發和維護一個限界上下文及其對應的模型.但是,管理不同團隊對領域模型的權限也會遇到挑戰(C16),因此必須確定團隊對領域模型的權限范圍.此外,是否允許團隊更改其他團隊的領域模型也很重要.以上決策將直接影響到模型的變更情況[38].比如:如果允許團隊更改其他團隊的限界上下文,服務之間的依賴會變得更加復雜.因此,應該權衡每個決策所帶來的損失和收益,從而做出最終決策.

最后,C17 與應用DDDP 進行軟件開發的過程相關.領域驅動設計的核心原則是,使應用程序與領域模型保持一致.正是這一特點,使得領域驅動設計區別于其他傳統的軟件開發方法[1].然而,雖然這一方法目前已經被廣泛接受,但是其對于如何在系統性軟件開發過程應用DDDP 并沒有提供詳細描述[30].這使得應用領域驅動設計的活動變得模糊不清,成為實踐者們面臨的主要挑戰,從而影響了適用性.

?緩解方法

解決C15[37]的一種途徑在于聚焦于信息架構[64],并在溝通中使用統一定義的術語(通用語言).為了提供對模型訪問和變更管理的支持(C16),文獻[48]論述了在分布式微服務開發背景下架構決策的優缺點,包括完全模型訪問和部分模型訪問,并提倡采用明確的策略來規范模型管理.為了應對C17,文獻[30]初步確定了DDD 開發活動集,并與需求確定和分析、設計和實現以及測試[31]等傳統軟件開發活動保持一致.

4 討論

本節綜合了基礎研究文獻中關于應用領域驅動設計模式的現有證據,對于應用DDDP 所面對的3 個問題進行了討論,包括應選擇戰術設計還是戰略設計、存在哪些機遇以及如何應對挑戰.

4.1 戰略設計與戰術設計

在DDDP 中,從戰略設計和戰術設計角度分別提供了一系列方法.戰略設計更關注業務的宏觀戰略方向[4],而戰術設計則聚焦于特定領域模型.本研究發現:相比于戰術設計,在DDD 社區中,實踐者更趨向于應用戰略設計(18.2%VS.45.5%).這可能是由于:對于企業而言,軟件系統的戰略設計決策更具有影響力.舉例而言:戰略設計能夠降低分析軟件架構時的認知復雜度,并能夠促進系統的組件化.

需要強調的是:實踐者不應只關注戰術設計,而忽略戰略設計.過分專注于技術層面可能會導致領域對象之間的細微差異被忽略,從而導致模型的錯誤融合,甚至會使系統變成大泥球(big ball of mud)[4].Millett 和Tune[5]認為,這正是許多應用DDD 的項目失敗的原因.因此,本文建議實踐者應該同時兼顧戰略設計和戰術設計,同時,根據自身業務場景來權衡戰略性設計和戰術設計的使用.

4.2 存在的機遇

現有經驗證據(empirical evidence)證明了DDDP 在軟件開發實踐中的實際應用價值.然而,在目前的基礎研究文獻中,僅有10 種DDDP 被明確指出對軟件開發有所幫助,而其他模式的實際價值還缺少相關證據的支持.

此外,諸如CQRS(command query responsibility segregation,命令查詢的責任分離)[65]等DDDP 的新興模式經過社區的發展已經日趨成熟,但由于這些模式并未包含在Evans 在2014年所提出模式列表中,因此學術界目前還缺少相應的研究工作.本文關注的基礎研究文獻中也缺少對這些模式的相關證據.

需要注意的是:雖然DDDP 是領域驅動設計標準化設計的重要內容[1],但對于DDD 而言,深入理解領域知識、迭代建模、統一模型與實現等整體愿景更為關鍵[1].為了實現以上愿景往往需要綜合應用多種DDDP,同時也需要保持團隊組織形式與軟件設計理念的一致性.

雖然應用DDDP 可以為軟件開發帶來良好的效果,但從現有研究來看,它對其他方面的幫助并不明顯.一方面,DDD 強調開發人員和領域專家及其他涉眾的協作,那么應用DDDP 來改善團隊組織結構似乎是合理的,比如上下文映射能夠明確地展示不同組織之間的動態關系,因此它可能適用于組織大型軟件項目的開發工作;另一方面,Vernon[4]認為,應用DDD 可能會使軟件過程的治理問題暴露出來.總的來說,現有研究缺乏對DDDP 的這些方面的討論,DDDP 在這些方面的具體作用仍需要更多的實證研究來驗證.

4.3 應對挑戰

正如Vernon[4]所說的,使用DDD 時仍需要面對諸多挑戰.在本研究的統計數據中,與挑戰相關的數據的來源研究文獻比較集中,這表明在目前的學術界研究中,還沒有對于應用DDDP 所面對的挑戰達成一致共識.這可能是因為現有的大多數研究工作所關注的主題都比較分散.我們推測:隨著DDD 研究的不斷深入,社區將對于應用DDDP 所面臨的挑戰逐漸會達成共識.

經過聚合分析[28],可以將本文所報告的應用DDDP 所面對的挑戰劃分整理成4 種類型,見表10.

?建模本身的復雜性:C2~C4,C10,C11.建模是軟件設計的一項重要活動,它決定了子系統的結構、接口、對象等.例如,C2 就與子系統結構的決策相關.設計決策是軟件設計的基礎,因此也存在許多相關研究,比如文獻[66?69].盡管這些挑戰背后的設計決策具有一定的特殊性,但一些觀點仍然可以為實踐者提供參考.比如在決策過程中,理性分析和主觀經驗都需要得到重視[27].具體而言,前者是根據預先定義的標準對備選決策進行評估和選擇,比如應用DDD 戰術設計模式進行實體與值對象的劃分時就需要理性分析;而后者則是根據經驗形成令人滿意的解決方案,比如在應用DDD 戰略設計模式來劃分限界上下文時,無法完全脫離設計者的主觀經驗.因此,本文建議實踐者在應對建模問題時既要進行理性決策,也要采納一些合理的主觀經驗;

?理解領域的困難:C1,C7,C9,C15.領域驅動設計要求在建模時與領域專家進行緊密配合[1],然而在具體實踐中,想要讓領域專家持續地參與建模過程并非易事,這需要軟件開發組織為領域專家增加一筆額外的開銷[4].此外,即使有領域專家的參與,開發團隊仍需要面對與領域專家進行溝通(如C7 和C15)和領域認知(C9)方面所存在的挑戰.本文建議實踐者增加對于理解領域這一過程的投入,并應用一些創新方法,如嘗試從多個角度(M12)來管理復雜性;

?對于除領域外的其他方面關注過少:C5,C12,C13.這些挑戰的重點在于,DDD 強調通過關注業務領域的建模來解決軟件開發的復雜性問題,因此,DDDP 也主要涉及建模方面,而缺少對其他方面(比如實現)的明確指導.上述挑戰可以通過補充工件或更加完善的規范來解決,比如領域層之外的工件(M6)和來自MDD 的中間模型(M14)等;

?DDD 理論的成熟度欠佳:C6,C8,C14,C16,C17.無論是通用語言還是戰略和戰術設計模式,都是DDD 所提供的抽象指導,實踐者仍然缺乏應用這些DDDP 進行軟件開發所需要的工具、方法以及過程管理等成熟能力.因此,在DDD 領域未來的研究工作中,可以考慮通過提出創新性解決方案(如M7)或者參考其他軟件工程社區中已有方法(如M17),為將DDDP 規范化地應用于軟件開發過程提供更完善的支持.

Table 10 Classification of the challenges of applying DDD patterns表10 應用DDDP 的挑戰分類

為便于理解,本文將這4 類挑戰對應到領域驅動設計方法及其模式在軟件開發中扮演的角色,如圖7所示.

Fig.7 Relation ship between four categories of challenges圖7 4 類挑戰的關系

作為一種軟件設計方法,領域驅動設計旨在加速具有復雜領域邏輯的軟件項目開發[1].領域驅動設計利用一系列DDDP 從領域邏輯中抽象領域模型的過程,從本質上看,可以理解為用戶應用軟件的領域(即問題空間)到可運行的軟件(即解空間)之間的映射和轉換.這個過程大體上可以分為兩個階段:對問題空間的理解和基于對問題空間的理解設計解空間.相應地,應用DDDP 面臨著理解問題空間時“理解領域的困難”挑戰以及基于對問題空間的理解設計解空間時“建模本身的復雜性”挑戰.另外,這個過程還面臨著“DDD 理論的成熟度欠佳”挑戰.由于軟件開發除領域邏輯外還需解決技術等其他難題,在實際軟件項目開發中落地DDDP 還面臨著“對于除領域外的其他方面關注較少”挑戰.

對于應對實踐DDDP 時所面臨挑戰的緩解方法而言,既有積極的一面,也有消極的一面.

?在積極的一面,這些緩解方法代表了實踐者為應對DDDP 所帶來的挑戰而做的努力:首先,一些緩解方法代表了DDD 實踐者當前的最佳實踐,比如利用事件風暴(event storming)來探索領域(M4)和建模規約(modeling conventions)(M13);其次,為了更好地應用DDDP,領域驅動設計的實踐者們付出大量努力,包括提出UML 配置文件(M7)和元模型(M8)等解決方案;最后,一些緩解方法中展現了從其他方法論中借鑒來的智慧,如中間模型(M14)和領域視圖(M12)等;

?在消極的一面,DDDP 的應用中仍然存在很多問題:首先,盡管針對C6 的緩解方法,也就是UML 配置文件(M7)和元模型(M8)具有一定效果,但它們違背了Evans 的初衷[30],具體而言,雖然M7 和M8 可以在一定程度上使領域模型標準化,并減少歧義,但由于它們增加了更多的規則約束,所以也降低建模過程的創造性;除此之外,一些緩解方法僅僅根據案例研究進行了評估,還缺少進一步的驗證,比如C8 的建模工具和軟件開發過程概覽(M17);最后,一些緩解方法本身并不容易實施,因為這些方法既沒有給出系統性的指導,也沒有給出具體實施的提示.

4.4 對研究者的啟示

在目前關于DDDP 的學術研究中,已發表研究文獻的主要關注點是對DDDP 詳細內容的完善和在軟件項目中應用DDDP 兩類,主要貢獻也集中于提出新的方法或者總結應用DDDP 的實踐經驗.然而,在軟件工程中是“沒有銀彈”的,任何理論方法都會存在一定的局限性和缺點,DDDP 也是如此.相比于已經廣泛應用DDD 理論的軟件工業界而言,對于DDDP 應用的反思,在學術研究文獻中還比較少見.

此外,DDD 應用實踐時除了需要掌握以領域為中心的思考方式之外,還應該能夠熟練地掌握正確應用包括戰略和戰術設計方面在內的各種DDDP.然而,相關研究文獻以及著作中所論述的DDDP 應用策略都比較抽象,這使得在實際情況下應用DDDP 還缺少系統性的指導方法和良好實踐,DDDP 的應用在很大程度上仍依賴于主觀經驗.因此,未來研究者可以考慮細化應用DDDP 的指導方法,并提出或總結更多可供參考的良好實踐.

5 效度威脅討論

本系統文獻綜述的工作中存在的效度威脅來源于文獻篩選、數據抽取及數據合成過程中可能存在的偏見.

為了消除檢索字符串及數據庫選擇中存在的偏見,我們在自動檢索之前進行了手動檢索并確保:①手動檢索中出現的每個DDD 同義詞都已被合并到檢索字符串中;②手動檢索獲得的每篇文獻都包含在自動檢索結果集合中.之后,我們通過滾雪球過程對于每個DDDP 所執行的單獨自動檢索結果進行補充.此外,本研究還預定義了一個已知的論文集合,以檢查檢索過程的全面性和準確性.為了避免文獻篩選出現錯誤,每篇文獻均由至少兩名作者獨立篩選與評估,然后通過二次審核過程進行合并.在這個過程中,我們使用了Kappa 分析確保足夠的可靠性[18].

在數據抽取與合成部分,效度威脅主要源于抽取過程中可能遺漏了有價值的文本數據,從而導致合成過程得出不準確的結論.為了避免遺漏有價值的文本數據,本研究在進行數據抽取過程之前先進行了小規模實驗,并按照作者的理解對數據抽取形式進行了調整.基于實驗調整后的數據項形式,兩名作者獨立地對每篇研究文獻進行數據抽取,并在最后進行合并.為了減少數據合成過程中得出的不準確的結論,作者們首先對DDD 相關書籍[1,4,18,70?72]進行學習和探討,從而熟悉DDD 社區.之后,兩名作者獨立進行編碼過程,并與第三名作者協商解決這一過程中存在的沖突或疑問.同時,在本研究中通過對于編碼結果的兩次復核,保證了對結果的改進.

6 總結與展望

本文面向領域驅動設計模式這一主題進行了系統文獻綜述,通過對2003年~2019年7月的研究文獻進行識別、檢索、篩選和分析,最終綜合26 篇高質量基礎研究來回答所本文所提出的研究問題.本文提供了學術界對于DDDP 應用的研究現狀概覽,同時比較全面地綜述了基礎研究中應用DDDP 帶來的收益、挑戰以及應對挑戰的緩解方法.

一方面,本文的研究表明:由于重視領域知識,實踐者往往能夠借助DDDP 設計出良好的軟件,并享受到其所帶來的收益,如架構質量改善和代碼意圖清晰.另一方面,本文的數據綜合結果表明:46.4%的基礎研究認為在DDDP 的實踐中存在很多困難,并將其總結為17 個挑戰.本研究中還發現了17 種緩解方法,用于應對上述提到的部分挑戰.雖然這些緩解方法還不足以完美地支撐DDDP 的應用實踐,但是它們代表了實踐者所付出的努力.正是這些該領域的理論和研究的不完善之處,為研究者和實踐者們提供了更加廣闊的探索空間.

目前,應用領域驅動設計模式在實踐中的價值得到了比較廣泛的認可,但對于如何更好地享受其所帶來的收益,以及更加合理地應對其帶來的挑戰,則需要研究者進一步探索.與此同時,在軟件工程中,沒有任何一種技術能夠稱為“銀彈”,因此,應用各種DDDP 所帶來的局限或者挑戰,仍需要未來進一步探索和反思.