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

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

2(計(jì)算機(jī)軟件新技術(shù)國家重點(diǎn)實(shí)驗(yàn)室(南京大學(xué)),江蘇 南京 210023)

3(安徽大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,安徽 合肥 230601)

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(domain-driven design,簡稱DDD)是一種在軟件設(shè)計(jì)中應(yīng)該遵循的思維方式,其目標(biāo)在于加快具有復(fù)雜需求的軟件項(xiàng)目的研發(fā)速度[1].DDD 中最重要的理念是通過構(gòu)建領(lǐng)域模型來解決軟件開發(fā)的復(fù)雜性問題[1],因?yàn)樵诖蠖鄶?shù)軟件項(xiàng)目中,最困難的往往是解決業(yè)務(wù)領(lǐng)域復(fù)雜性,而非技術(shù)復(fù)雜性.DDD 的一個(gè)顯著特征就是設(shè)計(jì)與開發(fā)的綁定,DDD 強(qiáng)調(diào)軟件設(shè)計(jì)概念必須在開發(fā)過程中得以成功實(shí)現(xiàn)[2].為了實(shí)現(xiàn)以上這些愿景,在DDD 方法中,將一組設(shè)計(jì)實(shí)踐、技術(shù)和原則合并為標(biāo)準(zhǔn)模式,即所謂的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)模式(domain driven design pattern,簡稱DDDP)[1],它們則構(gòu)成了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的主體.

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

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

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

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

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

本文第1 節(jié)介紹DDDP 的背景知識(shí).第2 節(jié)介紹本文所采用的系統(tǒng)文獻(xiàn)綜述方法.第3 節(jié)給出綜述的結(jié)果.第4 節(jié)對(duì)于綜述結(jié)果進(jìn)行深入分析和討論.第5 節(jié)分析本研究中存在的效度威脅.最后,第6 節(jié)給出對(duì)于應(yīng)用DDDP 的總結(jié)與展望.

1 背景介紹

1.1 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的本質(zhì)

領(lǐng)域模型(domain model)作為設(shè)計(jì)具有復(fù)雜業(yè)務(wù)規(guī)則的企業(yè)應(yīng)用程序的一種軟件設(shè)計(jì)模式,該模式可以被看作是一個(gè)具有行為和數(shù)據(jù)的領(lǐng)域?qū)ο竽Ｐ蚚16].領(lǐng)域模型正是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的基礎(chǔ).具體而言,DDD 方法說明了如何利用DDDP 從業(yè)務(wù)中抽象出領(lǐng)域模型,并將其置于軟件開發(fā)的核心位置[1].

DDD 具有幾個(gè)基本原則.

?第一,在首先提出DDD 的書籍中[1],Evans 強(qiáng)調(diào)設(shè)計(jì)概念必須在代碼中成功實(shí)現(xiàn),否則,它們將會(huì)變成抽象的討論.DDD 通過引入模型驅(qū)動(dòng)設(shè)計(jì)(model driven design)建模范式及其構(gòu)造塊,彌補(bǔ)了模型與可運(yùn)行的軟件之間的差距;

?第二,DDD 還提倡迭代開發(fā),并說明了如何借助敏捷[17]中的迭代式領(lǐng)域建模加速軟件開發(fā)[1].領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與具體實(shí)現(xiàn)過程間的緊密關(guān)系,使得DDD 比其他軟件設(shè)計(jì)方法更具有實(shí)用性;

?第三,在實(shí)踐DDD 的過程中,開發(fā)人員和領(lǐng)域?qū)＜抑g需要展開緊密協(xié)作,這是因?yàn)镈DD 追求的領(lǐng)域模型需要依靠頭腦風(fēng)暴的創(chuàng)造性和對(duì)領(lǐng)域的深入了解[1];

?第四,DDD 是一種軟件設(shè)計(jì)方法,而任何設(shè)計(jì)出來的領(lǐng)域模型都應(yīng)該與架構(gòu)無關(guān)[4].也就是說,除了領(lǐng)域模型,在軟件開發(fā)過程中仍然需要架構(gòu)設(shè)計(jì),比如微服務(wù)架構(gòu)和六邊形架構(gòu)[4].

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

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

對(duì)于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)而言,最基本的模式是通用語言(ubiquitous language),它是一種供不同涉眾(如開發(fā)人員和領(lǐng)域?qū)＜?共同使用的語言,主要用于輔助領(lǐng)域建模[4].一種通用語言只適用于單個(gè)限界上下文(bounded context),后者作為一個(gè)顯式的模型邊界來維護(hù)模型的完整性.根據(jù)Vernon[4]的觀點(diǎn),除了通用語言之外的DDDP,要么屬于戰(zhàn)略設(shè)計(jì)模式(strategic design pattern),要么屬于戰(zhàn)術(shù)設(shè)計(jì)模式(tactical design pattern).

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

戰(zhàn)術(shù)設(shè)計(jì)模式負(fù)責(zé)根據(jù)通用語言對(duì)單個(gè)限界上下文進(jìn)行領(lǐng)域建模[4],并結(jié)合面向?qū)ο蟮脑瓌t來綁定領(lǐng)域建模和編碼實(shí)現(xiàn).戰(zhàn)術(shù)建模的典型模式包括實(shí)體(entity)、值對(duì)象(value object)、聚合(aggregate)、服務(wù)(service)、資源庫(repository)等.具體來講:實(shí)體和值對(duì)象用于對(duì)具有不同領(lǐng)域特征的領(lǐng)域?qū)ο筮M(jìn)行建模;聚合將一組領(lǐng)域?qū)ο蠼壎橐粋€(gè)整體,以控制事務(wù);服務(wù)則充當(dāng)領(lǐng)域模型的接口,具有無狀態(tài)的特點(diǎn);而資源庫則用于封裝領(lǐng)域?qū)ο蟮臄?shù)據(jù)庫訪問操作.

2 綜述方法

本系統(tǒng)性文獻(xiàn)綜述根據(jù)Kitchenham 等人的指南[18]開展研究.本節(jié)首先提出驅(qū)動(dòng)本工作開展的研究問題,其次描述了數(shù)據(jù)收集所遵循的詳細(xì)策略和流程,最后描述了本研究的數(shù)據(jù)抽取和合成過程.

2.1 研究問題

本研究的總體目標(biāo)是形成在軟件開發(fā)中應(yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)模式的系統(tǒng)性理解,了解應(yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)模式的實(shí)踐情況,包括其帶來的收益、挑戰(zhàn)及應(yīng)對(duì)挑戰(zhàn)的緩解方法.為此,本研究提出了如表1所示的具體研究問題.其中:研究問題1 是為了了解DDDP 在軟件開發(fā)項(xiàng)目中的應(yīng)用現(xiàn)狀;研究問題2 是為了調(diào)研應(yīng)用DDDP 所帶來的收益情況;研究問題3 是為了總結(jié)應(yīng)用DDDP 所面對(duì)的挑戰(zhàn)以及應(yīng)對(duì)挑戰(zhàn)的緩解方法,并挖掘未來可能的研究方向.

2.2 文獻(xiàn)收集

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

Fig.1 Literaturecollection procedure圖1 文獻(xiàn)收集過程

2.2.1 文獻(xiàn)檢索

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

?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].

接下來對(duì)檢索過程的一些關(guān)鍵步驟進(jìn)行詳細(xì)說明.

(1)手動(dòng)檢索

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

①已知文獻(xiàn)集合的出版源;

②軟件設(shè)計(jì)和架構(gòu)相關(guān)的期刊與會(huì)議.

手動(dòng)檢索的過程首先由本文的兩位作者獨(dú)立進(jìn)行,之后將檢索結(jié)果合并到一起,即:只要一位作者認(rèn)為該文獻(xiàn)與本研究相關(guān),就會(huì)被納入此階段的文獻(xiàn)集合中.

表2 展示了從各個(gè)出版源檢索到的相關(guān)文獻(xiàn)數(shù)量.

Table 2 Publication venues included in manual search表2 手動(dòng)檢索的出版源

(2)自動(dòng)檢索

在這一階段,本文作者檢索了3 個(gè)主要的在線學(xué)術(shù)數(shù)字圖書館:①IEEE Xplore(https://ieeexplore.ieee.org/Xplore);②ACM Digital Library(https://dl.acm.org);和③ScienceDirect(https://www.sciencedirect.com);以及一個(gè)索引系統(tǒng):④Scopus(https://www.scopus.com).對(duì)于檢索字符串,本文作者確定了研究問題中最普遍的關(guān)鍵字(即“DDD”),并決定只包含它和它的相關(guān)同義詞進(jìn)行檢索,這些同義詞是從手動(dòng)檢索結(jié)果和已知的論文集合中獲得的.通過合并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*”)

每個(gè)檢索源的詳細(xì)檢索結(jié)果見表3.

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

(3)滾雪球

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

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

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

(4)DDDP 的自動(dòng)檢索

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

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

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

2.2.2 文獻(xiàn)篩選

本系統(tǒng)文獻(xiàn)綜述使用的文獻(xiàn)納入和排除標(biāo)準(zhǔn)如下所示.注意,只有符合所有納入標(biāo)準(zhǔn)的基礎(chǔ)研究文獻(xiàn)才會(huì)被納入,而符合任何一項(xiàng)排除標(biāo)準(zhǔn)的文獻(xiàn)都將被排除.

(1)納入標(biāo)準(zhǔn)(include criteria)

?IC1:文獻(xiàn)提供了關(guān)于DDD 的某種形式的數(shù)據(jù).在這一階段,我們的目標(biāo)是最大限度地?cái)U(kuò)大文獻(xiàn)范圍,以確保研究的完整性;

(2)排除標(biāo)準(zhǔn)(exclude criteria)

?EC1:發(fā)表于2003年DDD 被發(fā)表之前的文獻(xiàn)(因?yàn)镈DD 于2003年被提出);

?EC2:無法獲得電子版全文的文獻(xiàn);

?EC3:用英語以外的語言撰寫的文獻(xiàn);

?EC4:沒有經(jīng)過同行評(píng)審的文獻(xiàn);

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

具體篩選過程如下:

?前期準(zhǔn)備:按主題篩選——我們通過瀏覽自動(dòng)檢索得到的每篇文獻(xiàn)的標(biāo)題,并確定其是否屬于軟件工程領(lǐng)域.注意,這個(gè)階段是專門為自動(dòng)檢索設(shè)計(jì)的,因?yàn)橐恍?shù)字圖書館(例如Scopus 和ScienceDirect)不支持基于主題的篩選,或者其基于主題的篩選功能相對(duì)有限;

?第1 階段:按標(biāo)題篩選——我們通過瀏覽手動(dòng)檢索、自動(dòng)檢索以及滾雪球所得到的文獻(xiàn)列表的標(biāo)題,以確定哪些文獻(xiàn)符合納入/排除標(biāo)準(zhǔn);

?第2 階段:按關(guān)鍵詞和摘要篩選——我們分析通過第1 階段的文獻(xiàn)的關(guān)鍵詞和摘要,進(jìn)一步確定它們是否符合選擇標(biāo)準(zhǔn);

?第3 階段:閱讀全文篩選——我們通讀了通過前兩個(gè)階段的文獻(xiàn)全文,并保留符合預(yù)先定義的篩選標(biāo)準(zhǔn)的文獻(xiàn).

表5 給出了篩選過程的中間結(jié)果.

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

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

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

?從手動(dòng)檢索中選取的所有文獻(xiàn)都包含在自動(dòng)檢索的選擇結(jié)果中.

2.2.3 質(zhì)量評(píng)估與模式識(shí)別

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

在經(jīng)過質(zhì)量評(píng)估之后,本研究進(jìn)行了模式識(shí)別,進(jìn)一步排除了沒有提及任何DDDP 的基礎(chǔ)研究(圖1).之所以將模式識(shí)別作為一個(gè)環(huán)節(jié)而不是一項(xiàng)文獻(xiàn)篩選標(biāo)準(zhǔn),是因?yàn)橐恍┠繕?biāo)文獻(xiàn)可能在另一些文獻(xiàn)的滾雪球階段被納入進(jìn)來,而后者可能并沒有提及任何DDDP 而只與領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)理論相關(guān).這樣做的目的是在收集文獻(xiàn)時(shí)盡可能全面地覆蓋相關(guān)文獻(xiàn).我們排除了手動(dòng)檢索和自動(dòng)檢索中的11 篇論文以及滾雪球檢索中的1 篇論文,最終得到了26 篇高質(zhì)量基礎(chǔ)研究.

2.3 數(shù)據(jù)抽取與合成

首先給出指導(dǎo)數(shù)據(jù)抽取過程的數(shù)據(jù)抽取項(xiàng),然后描述對(duì)數(shù)據(jù)抽取結(jié)果的合成(synthesis)方法.在數(shù)據(jù)抽取和合成環(huán)節(jié)中,我們主要使用Nvivo(https://www.qsrinternational.com/nvivo)和電子表格來記錄數(shù)據(jù).

2.3.1 數(shù)據(jù)抽取

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

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

Table 6 Data extraction items表6 數(shù)據(jù)抽取項(xiàng)

2.3.2 數(shù)據(jù)合成方法

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

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

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

3 研究結(jié)果

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

對(duì)于DDDP 應(yīng)用框架的進(jìn)一步說明如下.

?領(lǐng)域分析是指與領(lǐng)域?qū)＜乙黄鹛剿黝I(lǐng)域知識(shí)的過程.經(jīng)過領(lǐng)域分析,將得到初始的領(lǐng)域模型;

?領(lǐng)域設(shè)計(jì)是指將模型分成不同部分(每個(gè)部分對(duì)應(yīng)著獨(dú)立的限界上下文),然后擴(kuò)展和細(xì)化每個(gè)限界上下文的過程,以此為開發(fā)實(shí)現(xiàn)做準(zhǔn)備;

?領(lǐng)域模型實(shí)現(xiàn)是指將模型轉(zhuǎn)換為可運(yùn)行代碼,這一過程還通過檢查模型為模型設(shè)計(jì)提供反饋;

?普適性活動(dòng)指的是應(yīng)用DDDP 時(shí),可能在領(lǐng)域分析、領(lǐng)域設(shè)計(jì)、領(lǐng)域模型實(shí)現(xiàn)這3 個(gè)階段都會(huì)發(fā)生的橫切活動(dòng),比如構(gòu)建和更新通用語言.

值得一提的是:在這些活動(dòng)中,開發(fā)團(tuán)隊(duì)可能對(duì)領(lǐng)域產(chǎn)生更深刻的洞察,并變更之前所做的設(shè)計(jì)決策.

Fig.2 An overview of activities in applying DDD patterns圖2 應(yīng)用DDDP 的活動(dòng)概覽

3.1 研究文獻(xiàn)的總體情況

經(jīng)過收集,本研究總共獲得了26 項(xiàng)基礎(chǔ)研究,本部分將簡要介紹這些相關(guān)研究的總體情況.

?出版年份

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

Fig.3 Distribution of literatures by years圖3 文獻(xiàn)發(fā)表年份分布

?作者來源

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

Fig.4 Distribution of literatures by authorship圖4 文獻(xiàn)作者來源分布

?研究形式

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

Fig.5 Distribution of literatures bystudy form圖5 文獻(xiàn)研究類型分布

?貢獻(xiàn)類型

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

Fig.6 Distribution of literaturesbycontribution type圖6 文獻(xiàn)貢獻(xiàn)類型分布

3.2 DDDP的應(yīng)用情況(RQ1)

表7 總結(jié)了在基礎(chǔ)研究集合中,出現(xiàn)頻次到達(dá)3 次以上的DDDP,以及對(duì)應(yīng)的描述和提及這些模式的研究文獻(xiàn).顯然,這些模式出現(xiàn)的頻次并不平衡.其中,戰(zhàn)術(shù)設(shè)計(jì)模式被提及的頻次明顯高于戰(zhàn)略設(shè)計(jì),這與Millett 和Tune[5]的發(fā)現(xiàn)基本一致,即,開發(fā)人員更容易注意到領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的戰(zhàn)術(shù)設(shè)計(jì)模式.總體而言,目前只有31.1%(14/45)的DDDP 在基礎(chǔ)研究中得到了探討,這也表明了當(dāng)前學(xué)術(shù)界對(duì)DDDP 的研究存在不足.

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

作為一種模式語言,DDD 由一組相互關(guān)聯(lián)的模式組成(即DDDP).Vernon[4]指出:如果在實(shí)踐中忽略通用語言和DDD 戰(zhàn)略設(shè)計(jì),而僅僅使用部分戰(zhàn)術(shù)設(shè)計(jì)模式,就可能導(dǎo)致領(lǐng)域概念之間的緊密耦合,這樣的問題被稱為“DDD-Lite 陷阱”.本研究發(fā)現(xiàn):在研究集合中,僅有文獻(xiàn)[30,41,42]明確地應(yīng)用了通用語言、戰(zhàn)略設(shè)計(jì)模式和戰(zhàn)術(shù)設(shè)計(jì)模式.有2 項(xiàng)研究可能落入了DDD-Lite 陷阱,因?yàn)樗鼈冎徽故玖藨?zhàn)術(shù)模型,而沒有提出任何與戰(zhàn)略層面實(shí)踐相關(guān)的觀點(diǎn).比如文獻(xiàn)[35]在文章中論述了他們?nèi)绾窝葸M(jìn)通用語言、戰(zhàn)術(shù)領(lǐng)域模型以及持久化策略等實(shí)現(xiàn)細(xì)節(jié),而并沒提及戰(zhàn)略設(shè)計(jì).與此同時(shí),5 篇研究文獻(xiàn)在研究中只采用了戰(zhàn)略設(shè)計(jì),而沒有關(guān)注戰(zhàn)術(shù)設(shè)計(jì).具體而言,這些研究專注于企業(yè)架構(gòu)層面,主要分析如何利用戰(zhàn)略模式(如限界上下文和上下文映射等)來組織具有多個(gè)領(lǐng)域模型的大規(guī)模結(jié)構(gòu).此外,基礎(chǔ)研究[40]較為特別,它既沒有論述戰(zhàn)略設(shè)計(jì),也沒有論述戰(zhàn)術(shù)設(shè)計(jì),而是分析了如何通過映射具有相似語義的領(lǐng)域概念,將兩種不同的戰(zhàn)術(shù)領(lǐng)域模型集成到一起.

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

為了便于讀者理解,本文以表格形式展現(xiàn)了將DDDP 應(yīng)用到DDD 活動(dòng)中的收益與挑戰(zhàn).表8 展示了應(yīng)用DDDP 所帶來的收益在領(lǐng)域分析、領(lǐng)域模型實(shí)現(xiàn)以及普適性活動(dòng)中的體現(xiàn)情況,并展示了相關(guān)模式和研究文獻(xiàn)的證據(jù)覆蓋范圍.除領(lǐng)域分析之外,本研究在DDD 活動(dòng)的各個(gè)階段均發(fā)現(xiàn)了應(yīng)用DDDP 所帶來的收益.

Table 8 Benefits of applying DDD Patterns表8 應(yīng)用DDDP 所帶來的收益

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

3.3.1 領(lǐng)域設(shè)計(jì)

在領(lǐng)域設(shè)計(jì)中,應(yīng)用DDDP 的收益在于能夠使各個(gè)領(lǐng)域之間的依賴關(guān)系更加明確(B1).上下文映射(context map)和職責(zé)分層(responsibility layer)用于組織系統(tǒng)的不同部分:前者表示不同限界上下文之間的關(guān)系,每個(gè)上下文表示一個(gè)特定的領(lǐng)域;后者則根據(jù)領(lǐng)域?qū)ο蟮穆氊?zé),將它們組織成具有清晰依賴關(guān)系的層次結(jié)構(gòu).借助這些DDDP,我們能夠清晰地認(rèn)識(shí)領(lǐng)域之間的關(guān)系和依賴.本質(zhì)上,正如基礎(chǔ)研究[53]所宣稱的,我們可以利用這些模式了解功能之間的依賴關(guān)系.因此在確定系統(tǒng)邊界時(shí),不同領(lǐng)域的戰(zhàn)術(shù)設(shè)計(jì)知識(shí)以及領(lǐng)域之間的關(guān)聯(lián)關(guān)系將變得更加明確.理清領(lǐng)域之間的依賴關(guān)系還可以幫助開發(fā)人員更加深入地了解系統(tǒng),降低認(rèn)知復(fù)雜性[52],有助于分析系統(tǒng)架構(gòu).

3.3.2 領(lǐng)域模型實(shí)現(xiàn)

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

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

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

3.3.3 普適性活動(dòng)

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

由于DDDP 中的通用語言能夠作為團(tuán)隊(duì)內(nèi)部的共享術(shù)語來降低溝通中的噪聲,所以在設(shè)計(jì)領(lǐng)域模型和分析代碼的過程中,通用語言能夠?yàn)椴煌纳姹娞峁└咝У耐ㄐ欧绞?B7).正是因此,領(lǐng)域?qū)＜业膮⑴c度得以大大提升,使得更多高價(jià)值的領(lǐng)域業(yè)務(wù)見解在團(tuán)隊(duì)內(nèi)部分享和傳遞.更好地理解業(yè)務(wù)(B8)能夠使得軟件與其所在的領(lǐng)域保持一致,這也正是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的基本觀點(diǎn)[4,29].另一方面,對(duì)于領(lǐng)域模型特別是核心域的關(guān)注,使開發(fā)人員能夠更好地理解正在開發(fā)的軟件和其未來愿景,有助于架構(gòu)決策的制定,如開發(fā)資源的高效利用(B10)和系統(tǒng)級(jí)優(yōu)化.

最后,應(yīng)用DDDP 能夠幫助復(fù)雜軟件架構(gòu)以更加敏捷的方式實(shí)現(xiàn)演進(jìn)(B9),并且能夠幫助團(tuán)隊(duì)?wèi)?yīng)對(duì)具有較大領(lǐng)域復(fù)雜性的軟件系統(tǒng)開發(fā)難題(B11).

3.4 應(yīng)用DDDP所面對(duì)的挑戰(zhàn)(RQ3)

總結(jié)現(xiàn)有研究中對(duì)于應(yīng)用DDDP 所帶來的挑戰(zhàn),能夠?yàn)閷W(xué)術(shù)界提供一些未來的研究方向.然而對(duì)于實(shí)踐者而言,其往往更關(guān)心應(yīng)對(duì)挑戰(zhàn)的策略和方法.盡管我們難以在現(xiàn)有研究中找到應(yīng)對(duì)DDDP 所帶來挑戰(zhàn)的“銀彈”,但研究文獻(xiàn)中所提出的一些方法,卻能夠幫助實(shí)踐者在一定程度上緩解應(yīng)對(duì)挑戰(zhàn)的難度,我們將其稱為挑戰(zhàn)的緩解方法.在本研究中,我們首先在基礎(chǔ)研究中提取了應(yīng)用DDDP 的17 個(gè)挑戰(zhàn),之后,3 位研究者根據(jù)所得到的挑戰(zhàn)列表和系統(tǒng)文獻(xiàn)綜述過程所收集的證據(jù),獨(dú)立抽取并合成應(yīng)對(duì)挑戰(zhàn)的緩解方法,經(jīng)過分析、討論與整合,最終得到了17 個(gè)應(yīng)對(duì)挑戰(zhàn)的緩解方法.

表9 列出了在領(lǐng)域分析、領(lǐng)域設(shè)計(jì)、領(lǐng)域模型實(shí)現(xiàn)和普適性活動(dòng)這些活動(dòng)中,應(yīng)用DDDP 可能面臨的挑戰(zhàn)以及相應(yīng)的緩解方法.接下來,本文將分階段對(duì)其進(jìn)行詳細(xì)介紹.

Table 9 Challenges of applying DDD Patterns表9 應(yīng)用DDDP 所需要面對(duì)的挑戰(zhàn)

Table 9 Challenges of applying DDD patterns(Continued)表9 應(yīng)用DDDP 所需要面對(duì)的挑戰(zhàn)(續(xù))

3.4.1 領(lǐng)域分析

在領(lǐng)域分析部分,本文發(fā)現(xiàn)了一種應(yīng)用DDDP 的挑戰(zhàn)(C1),但是并沒有在研究文獻(xiàn)中找到能夠緩解該挑戰(zhàn)的方法,因此在本部分的緩解方法中,本文根據(jù)經(jīng)驗(yàn)總結(jié)出了兩條應(yīng)對(duì)建議.

?挑戰(zhàn)

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)及模式致力于幫助開發(fā)組織深入理解軟件的業(yè)務(wù)領(lǐng)域,以便在系統(tǒng)開發(fā)中充分發(fā)揮創(chuàng)造力[39].為了更加深入地了解相關(guān)領(lǐng)域,無論是形成統(tǒng)一語言還是確定限界上下文和核心域,都強(qiáng)調(diào)領(lǐng)域?qū)＜遗c開發(fā)人員之間的緊密協(xié)作.然而,讓領(lǐng)域?qū)＜覅⑴c領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)實(shí)踐并非易事(C1),這成為了阻礙DDDP 成功應(yīng)用的一個(gè)主要障礙,特別是在所開發(fā)的軟件系統(tǒng)非常復(fù)雜,需要不同領(lǐng)域的多個(gè)領(lǐng)域?qū)＜夜餐瑓⑴c的情況下.Vernon[4]也認(rèn)同了這一觀點(diǎn),他認(rèn)為:讓領(lǐng)域?qū)＜覅⑴c軟件開發(fā)過程,一直以來都十分困難.

?緩解方法

在本研究所搜集的基礎(chǔ)研究文獻(xiàn)中,并沒有針對(duì)領(lǐng)域分析階段所遇到的C1 提出任何解決方案.顯然,C1 更像是一個(gè)組織問題,而不是技術(shù)問題.結(jié)合Vernon[4]的觀點(diǎn),我們?yōu)閼?yīng)對(duì)C1 提供了兩條建議:①如果軟件開發(fā)組織決定應(yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì),那么就應(yīng)該充分認(rèn)識(shí)領(lǐng)域?qū)＜业闹匾?②領(lǐng)域?qū)＜抑傅牟皇且粋€(gè)職位,而指的是非常了解業(yè)務(wù)線的人,因此,領(lǐng)域?qū)＜铱赡苁卿N售人員,也可能是產(chǎn)品設(shè)計(jì)師[4].

3.4.2 領(lǐng)域設(shè)計(jì)

在領(lǐng)域設(shè)計(jì)部分,本文發(fā)現(xiàn)了8 種應(yīng)用DDDP 所帶來的挑戰(zhàn)(即C2~C9),并且對(duì)于其中除了C3,C4 和C7 之外的5 項(xiàng)挑戰(zhàn)都發(fā)現(xiàn)了一些對(duì)應(yīng)的緩解方法(M1~M12).

?挑戰(zhàn)

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

將一個(gè)領(lǐng)域拆分為多個(gè)子域之后,應(yīng)首先識(shí)別出系統(tǒng)中最具決定性的子域,即核心域,并側(cè)重對(duì)核心域的投入,以實(shí)現(xiàn)收益最大化[4].但在實(shí)際中,對(duì)開發(fā)人員而言,識(shí)別系統(tǒng)的核心域往往非常困難(C3),尤其是在開發(fā)大型系統(tǒng)時(shí).此外,基礎(chǔ)研究[52]還發(fā)現(xiàn),在實(shí)踐中可能會(huì)同時(shí)存在多個(gè)核心域,因此進(jìn)一步加劇了這一挑戰(zhàn).

在每個(gè)限界上下文內(nèi)應(yīng)用戰(zhàn)術(shù)設(shè)計(jì)模式主要面臨兩個(gè)挑戰(zhàn):其一,確定聚合的粒度非常困難(C4),這需要在執(zhí)行單個(gè)事務(wù)的成本和強(qiáng)一致性兩者之間取得平衡[58];其二,使用分層架構(gòu)(layered architecture)將領(lǐng)域模型與其他模塊進(jìn)行對(duì)應(yīng)時(shí),DDDP 中并未對(duì)領(lǐng)域?qū)又獾钠渌麑?如用戶界面層、應(yīng)用程序?qū)雍突A(chǔ)設(shè)施層等,提供任何相關(guān)規(guī)范(C5)[1].本質(zhì)上講,領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)強(qiáng)調(diào)使用領(lǐng)域模型來展示領(lǐng)域的功能視圖,但并沒有考慮其他方面[30].然而,這種對(duì)領(lǐng)域?qū)又庖?guī)范的缺失,將會(huì)為實(shí)踐者帶來一定的困擾.

在模型中表達(dá)領(lǐng)域知識(shí)時(shí),Evans[1]強(qiáng)調(diào)可以利用各種媒介進(jìn)行溝通(不僅是UML[31])來最大化模型表達(dá)的效率.但這就帶來了另一項(xiàng)挑戰(zhàn),即,領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)缺乏對(duì)模型的形式化表達(dá)的支持(C6).文獻(xiàn)[44]指出:DDD 的定義不僅缺少形式化基礎(chǔ),還在某些情況下具有不同的表達(dá)方式.在應(yīng)用微服務(wù)架構(gòu)構(gòu)建應(yīng)用程序時(shí),領(lǐng)域模型將分散在不同團(tuán)隊(duì)中,因此具有相同語義的領(lǐng)域?qū)ο罂赡軙?huì)在不同團(tuán)隊(duì)中獨(dú)立演變,從而變得完全不同.這樣一來,很可能使得不同團(tuán)隊(duì)對(duì)相同的領(lǐng)域概念產(chǎn)生不同的理解[47].

在基礎(chǔ)研究文獻(xiàn)中還提到了其他的一些挑戰(zhàn),如基礎(chǔ)研究[46]所描述的,領(lǐng)域模型的建模過程需要領(lǐng)域?qū)＜业膮⑴c,但卻無法保證領(lǐng)域?qū)＜夷軌蚶斫饨＿^程中使用的全部技術(shù)(C7),這對(duì)于通用語言的實(shí)踐造成了一定困難.此外,當(dāng)前的建模工具還不能完全適用于領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(C8).最后一點(diǎn),雖然DDD 提供了多種模式,但是領(lǐng)域模型的復(fù)雜度依然會(huì)影響模型本身的可理解性(C9).

?緩解方法

為了確定限界上下文的合理粒度(C2),多個(gè)研究文獻(xiàn)給出了相關(guān)建議.首先,文獻(xiàn)[30,44]認(rèn)為,應(yīng)該考慮團(tuán)隊(duì)的組織結(jié)構(gòu).其次,文獻(xiàn)[41]建議找到職責(zé)的邊界,并將其作為該領(lǐng)域的業(yè)務(wù)功能.文獻(xiàn)[49]建議通過分析用例的工作流將相關(guān)功能聚集在一起,并將其劃分為不同的領(lǐng)域,也就是限界上下文;此外,通過將領(lǐng)域?qū)＜液烷_發(fā)人員召集在一起來討論業(yè)務(wù)領(lǐng)域的事件風(fēng)暴[60],也是一種行之有效的重要手段.通常而言,限界上下文往往需要經(jīng)過多次迭代才能夠最終確定,根據(jù)文獻(xiàn)[42]的經(jīng)驗(yàn),比較來自于不同團(tuán)隊(duì)的領(lǐng)域模型,有利于使領(lǐng)域邊界更清晰.

為了應(yīng)對(duì)微服務(wù)場景中的C5,也就是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)在其他層中沒有提供任何規(guī)范這一挑戰(zhàn),需要添加其他工件來彌補(bǔ)規(guī)范的缺失[30].根據(jù)Fairbanks[61]的建議,在決定向系統(tǒng)中增加新的工件時(shí),需要仔細(xì)考慮項(xiàng)目中存在的風(fēng)險(xiǎn).例如:當(dāng)使用DDD 構(gòu)建基于微服務(wù)的Web 應(yīng)用程序時(shí),文獻(xiàn)[30]根據(jù)用戶體驗(yàn)設(shè)計(jì)的指導(dǎo)原則來定義用戶界面和交互,根據(jù)行為驅(qū)動(dòng)開發(fā)(behavior-driven development)來確定應(yīng)用層的需求,并使用Spring 框架搭建基礎(chǔ)設(shè)施層.

為了使建模語言更加形式化(C6),基于在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中應(yīng)用UML 元素情況的調(diào)研,文獻(xiàn)[44]定義了一種用于建模的UML 配置文件(profile),并充分考慮到了各元素的語法和語義.應(yīng)用這種UML 配置文件的案例表明,其能夠?qū)⒒谶@種配置建模的領(lǐng)域模型映射到微服務(wù)中.文獻(xiàn)[48]的研究工作進(jìn)一步驗(yàn)證了這種UML 配置文件的有效性.除此之外,本體論是一種在特定領(lǐng)域中描述語義的方法,其能夠?qū)ο到y(tǒng)結(jié)構(gòu)進(jìn)行形式化建模,比如實(shí)體和關(guān)系等[62].基于本體論,基礎(chǔ)研究[47]提出了一種表達(dá)領(lǐng)域模型語義及關(guān)系的元模型,以此來確保整個(gè)團(tuán)隊(duì)對(duì)分布式領(lǐng)域驅(qū)動(dòng)微服務(wù)設(shè)計(jì)中的相關(guān)領(lǐng)域概念具有相同的理解.

對(duì)于建模工具(C8)而言,文獻(xiàn)[44]在Eclipse 和Papyrus 建模環(huán)境的基礎(chǔ)上實(shí)現(xiàn)了UML 配置文件;文獻(xiàn)[56]在Eclipse 平臺(tái)上開發(fā)了Elihu 項(xiàng)目,能夠?qū)τ陬I(lǐng)域?qū)ο笙嚓P(guān)的應(yīng)用功能進(jìn)行建模,而無需考慮基礎(chǔ)設(shè)施方面的問題.此外,文獻(xiàn)[48]建議使用另一個(gè)基于Eclipse 的工具——AjiL 來實(shí)現(xiàn)微服務(wù)的圖形化建模.AjiL 能夠通過建模得到初步的領(lǐng)域模型,并通過代碼生成器將模型轉(zhuǎn)化為微服務(wù)的具體實(shí)現(xiàn).

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

3.4.3 領(lǐng)域模型實(shí)現(xiàn)

在領(lǐng)域模型實(shí)現(xiàn)部分,本文發(fā)現(xiàn)了5 種應(yīng)用DDDP 的挑戰(zhàn)(即C10~C14),并且對(duì)于其中的C12 和C13 尋找到了對(duì)應(yīng)的緩解方法(M13,M14).

?挑戰(zhàn)

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

此外,由于DDD 側(cè)重于業(yè)務(wù)領(lǐng)域而非技術(shù)領(lǐng)域,這也帶來了兩項(xiàng)挑戰(zhàn).

?第一,DDD 中的領(lǐng)域模型沒有指定后續(xù)的實(shí)現(xiàn)規(guī)范(C12).舉例而言,領(lǐng)域?qū)ο蟮膶傩钥赡苁菬o類型的,或者缺少具體的行為方法[48].但是這類信息對(duì)于后續(xù)實(shí)現(xiàn)而言往往是必要的,而由于這類信息的缺失,使得從模型清晰地推斷出技術(shù)特性變得非常困難;

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

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

?緩解方法

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

3.4.4 普適性活動(dòng)

在普適性活動(dòng)部分,本文發(fā)現(xiàn)了3 種應(yīng)用DDDP 的挑戰(zhàn)(即C15~C17),并且對(duì)于其中的每個(gè)挑戰(zhàn)尋找到了對(duì)應(yīng)的緩解方法(M15~M17).

?挑戰(zhàn)

文獻(xiàn)[37]提到:在形成通用語言的過程中,由于不同涉眾使用的語言不同,往往難以對(duì)于同一術(shù)語形成統(tǒng)一認(rèn)識(shí)(C15).這使得團(tuán)隊(duì)在溝通過程中可能會(huì)產(chǎn)生誤解,想要定義通用語言往往需要付出更多的努力.

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

最后,C17 與應(yīng)用DDDP 進(jìn)行軟件開發(fā)的過程相關(guān).領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心原則是,使應(yīng)用程序與領(lǐng)域模型保持一致.正是這一特點(diǎn),使得領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)區(qū)別于其他傳統(tǒng)的軟件開發(fā)方法[1].然而,雖然這一方法目前已經(jīng)被廣泛接受,但是其對(duì)于如何在系統(tǒng)性軟件開發(fā)過程應(yīng)用DDDP 并沒有提供詳細(xì)描述[30].這使得應(yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的活動(dòng)變得模糊不清,成為實(shí)踐者們面臨的主要挑戰(zhàn),從而影響了適用性.

?緩解方法

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

4 討論

本節(jié)綜合了基礎(chǔ)研究文獻(xiàn)中關(guān)于應(yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)模式的現(xiàn)有證據(jù),對(duì)于應(yīng)用DDDP 所面對(duì)的3 個(gè)問題進(jìn)行了討論,包括應(yīng)選擇戰(zhàn)術(shù)設(shè)計(jì)還是戰(zhàn)略設(shè)計(jì)、存在哪些機(jī)遇以及如何應(yīng)對(duì)挑戰(zhàn).

4.1 戰(zhàn)略設(shè)計(jì)與戰(zhàn)術(shù)設(shè)計(jì)

在DDDP 中,從戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)角度分別提供了一系列方法.戰(zhàn)略設(shè)計(jì)更關(guān)注業(yè)務(wù)的宏觀戰(zhàn)略方向[4],而戰(zhàn)術(shù)設(shè)計(jì)則聚焦于特定領(lǐng)域模型.本研究發(fā)現(xiàn):相比于戰(zhàn)術(shù)設(shè)計(jì),在DDD 社區(qū)中,實(shí)踐者更趨向于應(yīng)用戰(zhàn)略設(shè)計(jì)(18.2%VS.45.5%).這可能是由于:對(duì)于企業(yè)而言,軟件系統(tǒng)的戰(zhàn)略設(shè)計(jì)決策更具有影響力.舉例而言:戰(zhàn)略設(shè)計(jì)能夠降低分析軟件架構(gòu)時(shí)的認(rèn)知復(fù)雜度,并能夠促進(jìn)系統(tǒng)的組件化.

需要強(qiáng)調(diào)的是:實(shí)踐者不應(yīng)只關(guān)注戰(zhàn)術(shù)設(shè)計(jì),而忽略戰(zhàn)略設(shè)計(jì).過分專注于技術(shù)層面可能會(huì)導(dǎo)致領(lǐng)域?qū)ο笾g的細(xì)微差異被忽略,從而導(dǎo)致模型的錯(cuò)誤融合,甚至?xí)瓜到y(tǒng)變成大泥球(big ball of mud)[4].Millett 和Tune[5]認(rèn)為,這正是許多應(yīng)用DDD 的項(xiàng)目失敗的原因.因此,本文建議實(shí)踐者應(yīng)該同時(shí)兼顧戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì),同時(shí),根據(jù)自身業(yè)務(wù)場景來權(quán)衡戰(zhàn)略性設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)的使用.

4.2 存在的機(jī)遇

現(xiàn)有經(jīng)驗(yàn)證據(jù)(empirical evidence)證明了DDDP 在軟件開發(fā)實(shí)踐中的實(shí)際應(yīng)用價(jià)值.然而,在目前的基礎(chǔ)研究文獻(xiàn)中,僅有10 種DDDP 被明確指出對(duì)軟件開發(fā)有所幫助,而其他模式的實(shí)際價(jià)值還缺少相關(guān)證據(jù)的支持.

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

需要注意的是:雖然DDDP 是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)標(biāo)準(zhǔn)化設(shè)計(jì)的重要內(nèi)容[1],但對(duì)于DDD 而言,深入理解領(lǐng)域知識(shí)、迭代建模、統(tǒng)一模型與實(shí)現(xiàn)等整體愿景更為關(guān)鍵[1].為了實(shí)現(xiàn)以上愿景往往需要綜合應(yīng)用多種DDDP,同時(shí)也需要保持團(tuán)隊(duì)組織形式與軟件設(shè)計(jì)理念的一致性.

雖然應(yīng)用DDDP 可以為軟件開發(fā)帶來良好的效果,但從現(xiàn)有研究來看,它對(duì)其他方面的幫助并不明顯.一方面,DDD 強(qiáng)調(diào)開發(fā)人員和領(lǐng)域?qū)＜壹捌渌姹姷膮f(xié)作,那么應(yīng)用DDDP 來改善團(tuán)隊(duì)組織結(jié)構(gòu)似乎是合理的,比如上下文映射能夠明確地展示不同組織之間的動(dòng)態(tài)關(guān)系,因此它可能適用于組織大型軟件項(xiàng)目的開發(fā)工作;另一方面,Vernon[4]認(rèn)為,應(yīng)用DDD 可能會(huì)使軟件過程的治理問題暴露出來.總的來說,現(xiàn)有研究缺乏對(duì)DDDP 的這些方面的討論,DDDP 在這些方面的具體作用仍需要更多的實(shí)證研究來驗(yàn)證.

4.3 應(yīng)對(duì)挑戰(zhàn)

正如Vernon[4]所說的,使用DDD 時(shí)仍需要面對(duì)諸多挑戰(zhàn).在本研究的統(tǒng)計(jì)數(shù)據(jù)中,與挑戰(zhàn)相關(guān)的數(shù)據(jù)的來源研究文獻(xiàn)比較集中,這表明在目前的學(xué)術(shù)界研究中,還沒有對(duì)于應(yīng)用DDDP 所面對(duì)的挑戰(zhàn)達(dá)成一致共識(shí).這可能是因?yàn)楝F(xiàn)有的大多數(shù)研究工作所關(guān)注的主題都比較分散.我們推測:隨著DDD 研究的不斷深入,社區(qū)將對(duì)于應(yīng)用DDDP 所面臨的挑戰(zhàn)逐漸會(huì)達(dá)成共識(shí).

經(jīng)過聚合分析[28],可以將本文所報(bào)告的應(yīng)用DDDP 所面對(duì)的挑戰(zhàn)劃分整理成4 種類型,見表10.

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

?理解領(lǐng)域的困難:C1,C7,C9,C15.領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)要求在建模時(shí)與領(lǐng)域?qū)＜疫M(jìn)行緊密配合[1],然而在具體實(shí)踐中,想要讓領(lǐng)域?qū)＜页掷m(xù)地參與建模過程并非易事,這需要軟件開發(fā)組織為領(lǐng)域?qū)＜以黾右还P額外的開銷[4].此外,即使有領(lǐng)域?qū)＜业膮⑴c,開發(fā)團(tuán)隊(duì)仍需要面對(duì)與領(lǐng)域?qū)＜疫M(jìn)行溝通(如C7 和C15)和領(lǐng)域認(rèn)知(C9)方面所存在的挑戰(zhàn).本文建議實(shí)踐者增加對(duì)于理解領(lǐng)域這一過程的投入,并應(yīng)用一些創(chuàng)新方法,如嘗試從多個(gè)角度(M12)來管理復(fù)雜性;

?對(duì)于除領(lǐng)域外的其他方面關(guān)注過少:C5,C12,C13.這些挑戰(zhàn)的重點(diǎn)在于,DDD 強(qiáng)調(diào)通過關(guān)注業(yè)務(wù)領(lǐng)域的建模來解決軟件開發(fā)的復(fù)雜性問題,因此,DDDP 也主要涉及建模方面,而缺少對(duì)其他方面(比如實(shí)現(xiàn))的明確指導(dǎo).上述挑戰(zhàn)可以通過補(bǔ)充工件或更加完善的規(guī)范來解決,比如領(lǐng)域?qū)又獾墓ぜ?M6)和來自MDD 的中間模型(M14)等;

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

Table 10 Classification of the challenges of applying DDD patterns表10 應(yīng)用DDDP 的挑戰(zhàn)分類

為便于理解,本文將這4 類挑戰(zhàn)對(duì)應(yīng)到領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)方法及其模式在軟件開發(fā)中扮演的角色,如圖7所示.

Fig.7 Relation ship between four categories of challenges圖7 4 類挑戰(zhàn)的關(guān)系

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

對(duì)于應(yīng)對(duì)實(shí)踐DDDP 時(shí)所面臨挑戰(zhàn)的緩解方法而言,既有積極的一面,也有消極的一面.

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

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

4.4 對(duì)研究者的啟示

在目前關(guān)于DDDP 的學(xué)術(shù)研究中,已發(fā)表研究文獻(xiàn)的主要關(guān)注點(diǎn)是對(duì)DDDP 詳細(xì)內(nèi)容的完善和在軟件項(xiàng)目中應(yīng)用DDDP 兩類,主要貢獻(xiàn)也集中于提出新的方法或者總結(jié)應(yīng)用DDDP 的實(shí)踐經(jīng)驗(yàn).然而,在軟件工程中是“沒有銀彈”的,任何理論方法都會(huì)存在一定的局限性和缺點(diǎn),DDDP 也是如此.相比于已經(jīng)廣泛應(yīng)用DDD 理論的軟件工業(yè)界而言,對(duì)于DDDP 應(yīng)用的反思,在學(xué)術(shù)研究文獻(xiàn)中還比較少見.

此外,DDD 應(yīng)用實(shí)踐時(shí)除了需要掌握以領(lǐng)域?yàn)橹行牡乃伎挤绞街?還應(yīng)該能夠熟練地掌握正確應(yīng)用包括戰(zhàn)略和戰(zhàn)術(shù)設(shè)計(jì)方面在內(nèi)的各種DDDP.然而,相關(guān)研究文獻(xiàn)以及著作中所論述的DDDP 應(yīng)用策略都比較抽象,這使得在實(shí)際情況下應(yīng)用DDDP 還缺少系統(tǒng)性的指導(dǎo)方法和良好實(shí)踐,DDDP 的應(yīng)用在很大程度上仍依賴于主觀經(jīng)驗(yàn).因此,未來研究者可以考慮細(xì)化應(yīng)用DDDP 的指導(dǎo)方法,并提出或總結(jié)更多可供參考的良好實(shí)踐.

5 效度威脅討論

本系統(tǒng)文獻(xiàn)綜述的工作中存在的效度威脅來源于文獻(xiàn)篩選、數(shù)據(jù)抽取及數(shù)據(jù)合成過程中可能存在的偏見.

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

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

6 總結(jié)與展望

本文面向領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)模式這一主題進(jìn)行了系統(tǒng)文獻(xiàn)綜述,通過對(duì)2003年~2019年7月的研究文獻(xiàn)進(jìn)行識(shí)別、檢索、篩選和分析,最終綜合26 篇高質(zhì)量基礎(chǔ)研究來回答所本文所提出的研究問題.本文提供了學(xué)術(shù)界對(duì)于DDDP 應(yīng)用的研究現(xiàn)狀概覽,同時(shí)比較全面地綜述了基礎(chǔ)研究中應(yīng)用DDDP 帶來的收益、挑戰(zhàn)以及應(yīng)對(duì)挑戰(zhàn)的緩解方法.

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

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