簡(jiǎn)介：?相較于常規(guī)的MVC架構(gòu)，DDD更抽象、更難以理解，各個(gè)開發(fā)者對(duì)DDD的解釋也不盡相同。那么哪種設(shè)計(jì)方式才更好？在學(xué)習(xí)時(shí)如何知道哪種DDD更正統(tǒng)，沒有被別人帶歪？本文嘗試使用“DDD as Code”的概念，即用DSL代碼方式來描述DDD，統(tǒng)一DDD的設(shè)計(jì)思想，通過案例詳細(xì)介紹如何基于ContextMapper來完成一個(gè)項(xiàng)目基于DDD DSL的表達(dá)，并分享現(xiàn)實(shí)中DDD的設(shè)計(jì)流程和微服務(wù)的關(guān)系。

?

網(wǎng)上有非常多關(guān)于DDD的文章，這當(dāng)然是好事情，大家都想掌握好的設(shè)計(jì)方法來解決軟件開發(fā)中的問題。但是這其中也存在一些問題，如果你隨便打開網(wǎng)上的幾篇DDD文章，雖然每一位作者都說自己是按照DDD思路進(jìn)行架構(gòu)設(shè)計(jì)的，但是細(xì)心的同學(xué)會(huì)發(fā)現(xiàn)每一個(gè)作者DDD文章中的結(jié)構(gòu)描述、畫的架構(gòu)圖都千差萬(wàn)別，你會(huì)非常奇怪，這些都是DDD設(shè)計(jì)嗎？這里其實(shí)有一個(gè)問題，就是通過文字和圖示描述一些抽象的概念時(shí)，本來就會(huì)有很大的差別。大家不要用盲人摸象的概念進(jìn)行類比，這個(gè)不太合適，即便兩個(gè)同學(xué)，對(duì)DDD都非常了解，而且都實(shí)踐了好幾年多個(gè)項(xiàng)目，他們寫出來的東西還是不一樣。我Java入行稍微早點(diǎn)，當(dāng)然你說我年紀(jì)大保守也可以，記得當(dāng)初沒有那么多中間件，就是基于Struts 1.x這個(gè)MVC框架進(jìn)行開發(fā)，不同的同學(xué)寫出的設(shè)計(jì)文檔也是千差萬(wàn)別。這么簡(jiǎn)單的MVC架構(gòu)都能有不同的架構(gòu)設(shè)計(jì)文檔，而DDD相對(duì)更抽象、更難以理解，所以架構(gòu)設(shè)計(jì)文檔長(zhǎng)的不太一樣，這個(gè)也是可以理解的。

那么我們是不是要接受這個(gè)事實(shí)，“各個(gè)作者對(duì)DDD的解釋可以不必相同”，"DDD設(shè)計(jì)文檔可以以不同種形式呈現(xiàn)"？如果是這樣，那么想學(xué)習(xí)DDD的同學(xué)就有非常大的負(fù)擔(dān)，哪種設(shè)計(jì)表現(xiàn)方式才是比較好的，才是比較容易理解的，同時(shí)我怎么知道我學(xué)的DDD是相對(duì)正統(tǒng)的，沒有被別人帶歪。我不是說發(fā)揮性思考不可以，但是從傳道的角度來說，尊重理論事實(shí)還是需要的。

我們都知道代碼在表達(dá)一些業(yè)務(wù)或者邏輯時(shí)，非常能反應(yīng)真實(shí)情況，即便是不同的開發(fā)者所編寫，考慮到遵循Design Pattern、命名規(guī)范、開發(fā)語(yǔ)言約束等，代碼大體上還是相同的，還是便于理解的，如果有單元測(cè)試和Code Review，那就更好啦。這也是在一些文檔不完善的時(shí)候，非常多同學(xué)選擇閱讀代碼，更有同學(xué)說，“直接看代碼，不要看他們PPT和文檔，會(huì)被誤導(dǎo)的，不然怎么死的都不知道”。另外我們都知道，現(xiàn)在一個(gè)非常好的實(shí)踐就是Everything as Code，典型的如Infrastructure as Code的Terraform，Platform as code的Kubernetes YAML, Diagram as Code的PlantUML等等， 那么我們能否使用DDD as Code這個(gè)概念，讓我們的設(shè)計(jì)更統(tǒng)一些，更能方便表達(dá)設(shè)計(jì)思想，更容易被人理解。

DDD DSL

用DSL也就是用代碼方式來表達(dá)DDD，這個(gè)很早就有了，但是更偏向DDD的戰(zhàn)術(shù)設(shè)計(jì)(Tactic Design)和代碼層面，如 Sculptor[1]和fuin.org DDD DSL[2] ，大家普遍都認(rèn)為，就是基于Xtext的DDD代碼生成器。要費(fèi)勁學(xué)習(xí)那么多，只為生成一些代碼，而且只是Java代碼，所以普遍關(guān)注度并沒有多高。

我們能否將DDD DSL除了代碼生成這一部分，更偏向于戰(zhàn)略設(shè)計(jì)(Strategic Design)，突出設(shè)計(jì)的思想，那么DDD as Code就全面多了。接下來我們就介紹ContextMapper這個(gè)框架。

名詞解釋一下：有不少同學(xué)對(duì)于DDD的戰(zhàn)略設(shè)計(jì)(Strategic Design) 和戰(zhàn)術(shù)(Tactic Design)之間區(qū)分有些疑惑，DDD有專門的介紹，如下：

• 戰(zhàn)術(shù)設(shè)計(jì)(Tactic DDD)：Entity, Value Object; Aggregate, Root Entity, Service, Domain Event; Factory, Repository。
• 戰(zhàn)略設(shè)計(jì)(Strategic DDD)：Bounded Context, Context Map; Published Language, Shared Kernel, Open Host Service, Customer-Supplier, Conformist, Anti Corruption Layer (context relationship types)。

其實(shí)也比較簡(jiǎn)單，戰(zhàn)略設(shè)計(jì)更大一些，偏宏觀，你可以理解為公司高層在討論的業(yè)務(wù)和技術(shù)方向，各個(gè)團(tuán)隊(duì)或者產(chǎn)品的分工和配合；而戰(zhàn)術(shù)設(shè)計(jì)則相對(duì)小很多，主要集中在一個(gè)BoundedContext內(nèi)部，比如如何設(shè)計(jì)DDD那些Entity，Service，Repository等，外加可能的應(yīng)用開發(fā)的技術(shù)選型，可以說更關(guān)注技術(shù)層面。

ContextMapper框架介紹

ContextMapper是一個(gè)開源項(xiàng)目[3] ，主要是為DDD設(shè)計(jì)提供DSL支持，如DDD的戰(zhàn)略(Strategic)設(shè)計(jì)，Context間映射(Context Mapping)，BoundedContext建模以及服務(wù)解耦(Service Decomposition)，那么我們就看一下如何基于ContextMapper來完成一個(gè)項(xiàng)目基于DDD DSL的表達(dá)。

在介紹ContextMapper時(shí)，我們先交代一下項(xiàng)目背景。如花是一名架構(gòu)師，對(duì)DDD也非常熟悉，而且有過幾個(gè)項(xiàng)目的DDD實(shí)踐，最近他加入會(huì)員線，負(fù)責(zé)完成對(duì)會(huì)員系統(tǒng)的改造，更好地配合公司的微服務(wù)化的設(shè)計(jì)思路。會(huì)員線之前就是三個(gè)應(yīng)用：會(huì)員中心對(duì)外提供的大量的REST API服務(wù)；會(huì)員注冊(cè)和登錄應(yīng)用；會(huì)員中心，處理會(huì)員登錄后如修改個(gè)人密碼、基本信息、SNS第三方綁定和支付方式綁定等。

如花加入會(huì)員團(tuán)隊(duì)后，和大家溝通了基于DDD + MicroServices的架構(gòu)思想，大家都表示同意，但是如何落實(shí)到具體的架構(gòu)設(shè)計(jì)和文檔上，大家就犯難啦。讓我們看一下最典型的DDD設(shè)計(jì)圖：

?

其中的概念，如SubDomain、BoundedContext、Entity、ValueObject、Service、 Repository、Domain Event，以及Context映射關(guān)系(Context Mapping)，這些都沒有問題，但是如何向他人表達(dá)這個(gè)思想？總不能每次都把DDD設(shè)計(jì)圖和分層圖都貼上去，然后說我就是按照DDD設(shè)計(jì)的。

從SubDomain開始

如花開始DDD的第一步，也就是Subdomain的劃分。當(dāng)然DDD中包括三種類型的SubDomain，分別為通用(Generic)、支撐(Supporting)和核心(Core)三種類型，這里稍微說明一下這幾者的區(qū)別：

• 通用(Generic) Domain: 通用Domain通常被認(rèn)為已經(jīng)被行業(yè)解決的問題，如架構(gòu)設(shè)計(jì)中的可觀測(cè)性的Logging、Metrics和Tracing，各種云服務(wù)(Cloud Service)等，這些都已經(jīng)有比較好的實(shí)現(xiàn)方案，對(duì)接就可以。當(dāng)然業(yè)務(wù)上也有，如成熟的行業(yè)解決方案，如ERP、CRM、成熟硬件系統(tǒng)等，你購(gòu)買就可以啦。
• 支撐(Supporting) Domain：和通用Domain類似，但是系統(tǒng)更來自內(nèi)部或者還需要在通用的基礎(chǔ)上進(jìn)行一些定制開發(fā)。如一個(gè)電商系統(tǒng)，會(huì)員、商品、訂單、物流等業(yè)務(wù)系統(tǒng)，當(dāng)然還有一些內(nèi)部開發(fā)的技術(shù)類型支撐系統(tǒng)。
• 核心(Core) Domain: 也就是我們常說的業(yè)務(wù)核心，當(dāng)然如果是技術(shù)產(chǎn)品，就是技術(shù)核心，這個(gè)也就是你最要關(guān)注的。

這三者整體關(guān)系如下：Core是最與眾不同且花費(fèi)精力比較多的，在復(fù)雜性Y維度，我們要避免高復(fù)雜度的通用和支撐Domain，這樣會(huì)分散你的注意力，同時(shí)還要投入非常大的精力，如果確實(shí)需要，購(gòu)買服務(wù)的方式可能最佳。

?

圖源：
https://github.com/ddd-crew/ddd-starter-modelling-process

如花首先將會(huì)員先劃分為幾個(gè)Sub Domain，如處理賬號(hào)相關(guān)的Account，處理會(huì)員打標(biāo)的UserTag，處理支付方式的PaymentProfile，處理社交平臺(tái)集成的SnsProfile，還有一個(gè)其他Profiles，這里我們不涉及Generic和Supporting Doman的規(guī)劃，主要從業(yè)務(wù)核心Domain出發(fā)。一個(gè)同學(xué)用PPT闡述了劃分結(jié)構(gòu)和出發(fā)點(diǎn)，如下：

?

但是也有同學(xué)說是不是UML的Component圖更好一些，方便和后面的UML圖統(tǒng)一，如下：

?

當(dāng)然還有其他如Visio等非常多的圖示工具用于展現(xiàn)結(jié)構(gòu)圖。DDD的第一步：SubDomain的劃分和展現(xiàn)，就有不同的理解方式，如何描述、如何圖形化展現(xiàn)，都有不少的分歧。

回到問題的出發(fā)點(diǎn)，我們就想劃分一下SubDomain，那么是不是下述的DSL代碼也可以：

Domain User {domainVisionStatement = "User domain to manage account, tags, profiles and payment profile."Subdomain AccountDomain {type = CORE_DOMAINdomainVisionStatement = "Account domain to save sensitive data and authentication"}Subdomain UserTagDomain {type = GENERIC_SUBDOMAINdomainVisionStatement = "UserTag domain manage user's KV and Boolean tag"}Subdomain PaymentProfileDomain {type = CORE_DOMAINdomainVisionStatement = "User payment profile domain to manage credit/debit card, Alipay payment information"}Subdomain SnsProfileDomain {type = CORE_DOMAINdomainVisionStatement = "User Sns profile domain to manage user Sns profile for Weibo, Wechat, Facebook and Twitter."}Subdomain ProfilesDomain {type = CORE_DOMAINdomainVisionStatement = "User profiles domain to manage user basic profile, interest profile etc"} }

雖然目前我們還不知道對(duì)應(yīng)的DSL代碼語(yǔ)法，但是我們已經(jīng)知道Domain的名稱、domain類型以及domain的愿景陳述(visionStatement)，至于后期以何種方式展現(xiàn)系統(tǒng)Domain，如表格、圖形等，這個(gè)可以考慮基于現(xiàn)在的數(shù)據(jù)進(jìn)行展現(xiàn)。其中的UserTagDomain類型為GENERIC_SUBDOMAIN，這個(gè)表示打標(biāo)是通用性Domain，如我們后期可以和商品、圖片或者視頻團(tuán)隊(duì)合作，大家可以一起共建打標(biāo)系統(tǒng)。

注意：Subdomain不只是簡(jiǎn)單包括type和domainVisionStatement，同時(shí)你可以添加Entity和Service，其目的主要是突出核心特性并方便你對(duì)Domain的理解，如Account中添加resetPassword和authBySmsCode，相信大多數(shù)人都知道這是什么含義。但是注意不要將其他對(duì)象添加到Subdomain，如VO, Repository, Domain Event等，這些都是輔助開發(fā)的，應(yīng)該用在BoundedContext中。

Subdomain AccountDomain {type = CORE_DOMAINdomainVisionStatement = "Account domain to save sensitive data and authentication"Entity Account {long idString nickString mobileString ^emailString nameString saltString passwdint statusDate createdAtDate updatedAt}Service AccountService {void updatePassword(long accountId, String oldPassword, String newPassword);void resetPassword(long acountId);boolean authByEmail(String email, String password);boolean authBySmsCode(String mobile, String code);}}

Context Map

ContextMap主要是描述各個(gè)Domain中各個(gè)BoundedContext間的關(guān)聯(lián)關(guān)系，你可以理解為BoundedContext的拓?fù)涞貓D。這里我們先不詳細(xì)介紹BoundedContext，你現(xiàn)在只需要理解為實(shí)現(xiàn)Domain的載體，如你編寫的HSF服務(wù)應(yīng)用、一個(gè)處理客戶請(qǐng)求的Web應(yīng)用或者手機(jī)App，也可以是你租用的一個(gè)外部SaaS系統(tǒng)等。舉一個(gè)例子，你的系統(tǒng)中有一個(gè)blog的SubDomain，你可以自行開發(fā)，也可以架設(shè)一個(gè)WordPress，或者用Medium實(shí)現(xiàn)Blog。回到微服務(wù)的場(chǎng)景，如何劃分微服務(wù)應(yīng)用？SubDomain對(duì)應(yīng)的是業(yè)務(wù)或者虛擬的領(lǐng)域，而BoundedContext則是具體支持SubDomain的微服務(wù)應(yīng)用，當(dāng)然一個(gè)SubDomain可能對(duì)應(yīng)多個(gè)微服務(wù)應(yīng)用。

既然是描述各個(gè)BoundedContext關(guān)系，必然會(huì)涉及到關(guān)聯(lián)關(guān)系，如DDD推薦的Partnership([P]<->[P])、Shared Kernel([SK]<->[SK])、Customer/Supplier([C]<-[S])、Conformist(D,CF]<-[U,OHS,PL])、Open Host Service、Anticorruption Layer([D,ACL]<-[U,OHS,PL])、Published Language等，詳細(xì)的介紹大家可以參考DDD圖書。這些對(duì)應(yīng)關(guān)系都有對(duì)應(yīng)的縮寫，就是括號(hào)內(nèi)的表述方法。這里給出關(guān)聯(lián)關(guān)系Cheat Sheet說明圖：

?

圖源：
https://github.com/ddd-crew/context-mapping

如果你自行畫圖來表達(dá)這些關(guān)系，一定有非常多的工作量，細(xì)致到箭頭類型，備注等，不然會(huì)引發(fā)誤解。這里我們就直接上ContextMapper DSL對(duì)ContextMap的描述方式，代碼如下：

ContextMap UserContextMap {type = SYSTEM_LANDSCAPEstate = TO_BEcontains AccountContextcontains UserTagContextcontains PaymentProfileContextcontains SnsProfileContextcontains ProfilesContextcontains UserLoginContextcontains UserRegistrationContextUserLoginContext [D]<-[U] AccountContext {implementationTechnology = "RSocket"exposedAggregates = AccountFacadeAggregate}ProfilesContext [D]<-[U] UserTagContext {implementationTechnology = "RSocket"exposedAggregates = UserTags}UserRegistrationContext [D,C]<-[U,S] UserTagContext {implementationTechnology = "RSocket"exposedAggregates = UserTags}UserRegistrationContext [D,C]<-[U,S] SnsProfileContext {implementationTechnology = "RSocket"} }

大家可以看到Map圖中包含的各個(gè)BoundedContext名稱，然后描述了它們之間的關(guān)系。在關(guān)聯(lián)關(guān)系描述中，涉及到對(duì)應(yīng)的描述。前面我們說明BoundedContext為Domain的具體系統(tǒng)和應(yīng)用的承載，所以涉及到對(duì)應(yīng)的技術(shù)實(shí)現(xiàn)。如HTTP REST API、RPC、Pub/Sub等，如blog系統(tǒng)為Medium的話，那么implementationTechnology = ”REST API"。還有exposedAggregates，表示暴露的聚合信息，如class對(duì)象和字段，服務(wù)接口等，方便通訊雙方做對(duì)接，這個(gè)我們會(huì)在BoundedContext中進(jìn)行介紹。

BoundedContext

在ContextMap中我們描述了它們之間的關(guān)聯(lián)關(guān)系，接下來我們要進(jìn)行BoundedContext的詳細(xì)定義。BoundedContext包含的內(nèi)容相信大多數(shù)同學(xué)都知道，如Entity， ValueObject，Aggregate，Service，Repository、DomainEvent等，這個(gè)大家應(yīng)該都比較熟悉。這里我們給出一個(gè)ContextMapper對(duì)BoundedContext的代碼，如下：

BoundedContext AccountContext implements AccountDomain {type = APPLICATIONdomainVisionStatement = "Managing account basic data"implementationTechnology = "Kotlin, Spring Boot, MySQL, Memcached"responsibilities = "Account", "Authentication"Aggregate AccountFacadeAggregate {ValueObject AccountDTO {long idString nickString nameint statusDate createdAtdef toJson();}/* AccountFacade as Application Service */Service AccountFacade {@AccountDTO findById(Integer id);}}Aggregate Accounts {Entity Account {long idString nickString mobileString ^emailString nameString saltString passwdint statusDate createdAtDate updatedAt}} }

這里對(duì)BoundedContext再說明一下：

• BoundedContext的名稱，這個(gè)不用說啦，這個(gè)和ContextMap中名稱一致。
• implements AccountDomain：表示要實(shí)現(xiàn)哪一個(gè)SubDomain，我們都知道一個(gè)Subdomain可能會(huì)包含多個(gè)BoundedContext，這些BoundedContext配合起來完成Subdomain的業(yè)務(wù)需求。ContextMap還提供refines，來表示BoundedContext要實(shí)現(xiàn)一些user case，官方文檔有對(duì)應(yīng)的說明。
• BoundedContext的屬性字段：type表示類型，如APPLICATION、SYSTEM等。domainVisionStatement描述一下BoundedContext的職責(zé)。implementationTechnology表示具體的技術(shù)，前面我們說到BoundedContext已經(jīng)涉及具體的應(yīng)用和系統(tǒng)等，所以要說明對(duì)應(yīng)的技術(shù)方案實(shí)現(xiàn)，核心的部分描述一下就可以。responsibilities 表示BoundedContext的職責(zé)列表，這里只需要關(guān)鍵字就可以，如Account要負(fù)責(zé)安全驗(yàn)證等。

• AccountFacadeAggregate: 表示提供給外部調(diào)用的聚合，這里DTO的對(duì)象定義、服務(wù)接口的定義等。
• Aggregate Accounts：這個(gè)表示BoundedContext內(nèi)部的聚合，如entity、value object、service等。這里說明一下，DDD中的那個(gè)Aggregate是entity，value object的聚合對(duì)象，而ContextMapper中的Aggregate表示為一些資源的集合，如Service集合等。

BoundedContext的更多信息，可以參考sculptor的文檔[4]，根據(jù)實(shí)際的情況可以添加對(duì)應(yīng)的部分，如DomainEvent、Repository等。

個(gè)人覺得這里BoundedContext還沒有涉及到Ubiquitous Language，還是需要對(duì)應(yīng)的輔助設(shè)計(jì)文檔，需要交代相關(guān)的項(xiàng)目背景，技術(shù)決策等等。個(gè)人是推薦采用C4架構(gòu)設(shè)計(jì)作者編寫的 《Visualise, document and explore your software architecture》[5]，非常實(shí)用，作為DDD架構(gòu)設(shè)計(jì)文檔，完全沒有問題。

文章的一開頭我們說到之前的DDD DSL更多的是代碼生成器，如果是代碼生成器，那么生成的代碼一定有對(duì)應(yīng)的規(guī)范和結(jié)構(gòu)等，如entity、value object，service，repository保存的目錄，生成的代碼可能還包括一定的Annotation或者interface，標(biāo)準(zhǔn)字段等等。當(dāng)然這里我們不討論代碼生成器的問題，但我們希望大家的DDD架構(gòu)設(shè)計(jì)還是要采用一定的規(guī)范目錄結(jié)構(gòu)，這里有幾個(gè)標(biāo)準(zhǔn)推薦給大家：

• ddd-4-java: Base classes for DDD with Java[6]

• jDDD：Libraries to help developers express DDD building blocks in Java code[7]
• ddd-base: DDD base package for java[8]

這三者其實(shí)出發(fā)點(diǎn)都是一致的，就是在代碼層面來描述DDD，核心是一些annotation、interface，base class，當(dāng)然也包括推薦的package結(jié)構(gòu)。

ContextMapper的其他特性

講到這里，其實(shí)DDD整體上來說，我們已經(jīng)闡述清楚：Domain劃分、整體Domain的BoundedContext拓?fù)鋱D和關(guān)聯(lián)關(guān)系、BoundedContext具體定義和架構(gòu)設(shè)計(jì)文檔規(guī)范。但是ContextMapper還提供了UserStory和UseCase對(duì)應(yīng)的DSL，讓我們來看一下。

UserStory

好多同學(xué)都問UserStory如何寫，有了這個(gè)DSL，同學(xué)們?cè)僖膊挥脫?dān)心如何編寫UserStory啦。這個(gè)DSL比較明確的，主要是三元素：作為 “aaa"，我希望能"xxx"，我希望能”yyyy"，以便 "zzz"， 也是符合UserStory的典型三要素：角色、活動(dòng)和商業(yè)價(jià)值。

UserStory Customers {As a "Login User"I want to update a "Avatar"I want to update an "Address"so that "I can manage the personal data." }

UseCase

Use Case是描述需求的一種方式，在UML圖就有對(duì)應(yīng)的UseCase圖，核心就是actor，交互動(dòng)作和商業(yè)價(jià)值，對(duì)應(yīng)的DSL代碼如下：

UseCase UC1_Example {actor = "Insurance Employee"interactions = create a "Customer", update a "Customer", "offer" a "Contract"benefit = "I am able to manage the customers data and offer them insurance contracts." }

在Aggregate聚合中，你可以設(shè)置useCases屬性來描述對(duì)應(yīng)的UseCase， 如下：

Aggregate Contract {useCases = UC1_Example, UC2_Example }

ContextMapper帶來的收益

按照你的說法，我們用DSL代碼方式來描述DDD，這個(gè)有什么收益？

架構(gòu)設(shè)計(jì)標(biāo)準(zhǔn)化

這種代碼方式，一目了然且非常規(guī)范。如果你代碼寫錯(cuò)會(huì)有什么問題，當(dāng)然是編譯不通過，IDE都會(huì)幫你糾正。所以DDD DSL也是這樣，完全無(wú)歧義。目前ContextMapper DSL包括Eclipse和VS Code插件，在IntelliJ IDEA可以通過自定義File Types和Live template方式來輔助你編寫cml文件。

生成器(Generators)支持

前面我們聊到DDD DSL支持代碼生成器，可以輔助你生成代碼，相信這個(gè)大家都能明白，因?yàn)镈DD DSL代碼是標(biāo)準(zhǔn)的，基于這個(gè)Code Model生成其他形式的代碼，這個(gè)當(dāng)然可以。

另外ContextMapper還支持其他模型生成，如ContextMap圖形化展現(xiàn)、PlantUML的結(jié)構(gòu)圖，對(duì)應(yīng)的代碼在這里[9]。我這里給大家一些截圖：

?

?

?

當(dāng)然ContextMapper還提供通用的生成器，也就是基于DDD DSL模型，加上Freemarker模板，然后就可以生成你想要的各種輸出，如生成JHipster Domain Language (JDL)用于快速創(chuàng)建文件腳手架也不奇怪。相信很多Java程序員對(duì)此都不陌生，我們開發(fā)Web應(yīng)用時(shí)就是使用Freemarker生成HTML的。更多細(xì)節(jié)訪問這里[10]。

現(xiàn)實(shí)中的DDD設(shè)計(jì)流程

我們有了DDD DSL來描述我們的架構(gòu)設(shè)計(jì)，是不是就全面了，完全夠用，開發(fā)不愁了呢。還不是，我們知道在軟件架構(gòu)設(shè)計(jì)和編寫代碼前，都有需求調(diào)研、客戶走訪、領(lǐng)域?qū)＜覝贤ā⑿枨蠓治觥⒀杏懙鹊?#xff0c;這個(gè)在現(xiàn)實(shí)生活中還是少不掉的，其目的就是為了后續(xù)的架構(gòu)設(shè)計(jì)提供素材并做鋪墊。那么如何將DDD和這些前期操作整合起來？其實(shí)DDD有涉及這方面的內(nèi)容，如EventStorming卡片：

?

Bounded Context Canvas卡片：

?

如果你在需求分析階段注意這些DDD卡片的使用，那么后續(xù)的DDD設(shè)計(jì)就會(huì)有更好的素材，當(dāng)然還有UserStory和Use Case等。

個(gè)人建議：如果你有時(shí)間的話，強(qiáng)烈建議關(guān)注一下ddd-crew[11] ，有非常全面的DDD相關(guān)的最新并實(shí)用的知識(shí)和實(shí)踐。

DDD和MicroServices的關(guān)系

和DDD DSL無(wú)關(guān)，只是稍微提及一下。微服務(wù)架構(gòu)設(shè)計(jì)在于如何將復(fù)雜的業(yè)務(wù)系統(tǒng)劃分為密切合作的微服務(wù)應(yīng)用，劃分的依據(jù)就顯得非常重要。SubDomain從業(yè)務(wù)的角度出發(fā)，進(jìn)行業(yè)務(wù)邊界的劃分，而BoundedContext則是關(guān)注于業(yè)務(wù)領(lǐng)域?qū)?yīng)的應(yīng)用承載。而Generic類型BoundedContext可以同時(shí)支撐多個(gè)SubDomain，能夠做到不同業(yè)務(wù)系統(tǒng)的應(yīng)用復(fù)用。如果在Cloud Native的場(chǎng)景中，我們希望更多的使用System類型的BoundedContext，也就是重復(fù)利用云上的系統(tǒng)，從而減少自己的開發(fā)和維護(hù)成本。回到Appplication類型的BoundedContext，這個(gè)就是你要具體開發(fā)的應(yīng)用，你選擇哪些微服務(wù)框架，這個(gè)你可以自行決定。整個(gè)過程，DDD都起到應(yīng)用劃分的理論基礎(chǔ)作用。

但這里還有一個(gè)問題，就是微服務(wù)之間的通訊問題，你可以反復(fù)強(qiáng)調(diào)我們需要構(gòu)建強(qiáng)大的分布式應(yīng)用，但是推薦的技術(shù)棧是什么？如何去做？而且還要做的更好，這個(gè)并沒有明確說明，所以大家選擇REST API、gRPC、RPC，Pub/Sub等等混合通訊技術(shù)棧。

關(guān)于BoundedContext之間的關(guān)聯(lián)關(guān)系DDD已經(jīng)給出了(partner ship, c/s, share kernel等)，但是具體到通訊和協(xié)作，并沒有給出很好的理論基礎(chǔ)， 但是這個(gè)在DDD社區(qū)也有一些共識(shí)，就是基于異步化的消息通訊 + 事件驅(qū)動(dòng)是比較好的方案，所以你看到DDD的首席布道師Vaughn Vernon反復(fù)講到DDD + Reactive，就是為了解決ContextMapping的通訊問題。

說到這里，如果你看到ContextMapper支持MDSL (Micro-)Service Contracts Generator的輸出，那么也就不奇怪了，也是理所當(dāng)然的事情。

更多的關(guān)于MicroServices和DDD關(guān)系，你可以參考《Microservices love Domain Driven Design, why and how?》[12]

總結(jié)

ContextMapper提出的DSL概念還是非常好的，至少讓大家在DDD的理解上歧義少啦，同時(shí)也規(guī)范啦，DDD初學(xué)者的門檻也降低，雖不能到架構(gòu)設(shè)計(jì)的地步，至少閱讀理解起來無(wú)障礙。在我編寫這篇文章的時(shí)候，ContextMapper DSL 5.15.0版本已經(jīng)發(fā)布，相關(guān)的特性都已經(jīng)全部開發(fā)完畢啦，使用起來還是非常順暢的。當(dāng)然落實(shí)到實(shí)際開發(fā)，DDD as Code這種方式是否有效，還希望做DDD實(shí)踐的同學(xué)給出寶貴的意見。

當(dāng)然我一篇文章并不能將ContextMapper闡述的非常清楚，contextmapper[13]上有非常詳細(xì)的文檔和對(duì)應(yīng)的相關(guān)論文， 當(dāng)然你可以不采用DSL這一套思路，但是這些思想和相關(guān)的資料對(duì)DDD設(shè)計(jì)還是幫助非常大的。

另外個(gè)人更覺得，如果你是DDD的初學(xué)者，那么ContextMapper可能更合適，DDD是方法論，那些圖書都枯燥的要死，看兩章節(jié)不犯困幾乎非常難的。相反如果你學(xué)習(xí)DDD DSL那就簡(jiǎn)單多，這個(gè)DSL再?gòu)?fù)雜也不會(huì)比你學(xué)習(xí)的編程語(yǔ)言復(fù)雜吧？相反這個(gè)DSL是非常簡(jiǎn)單的，通過簡(jiǎn)單的DDD DSL學(xué)習(xí)，你會(huì)很快掌握其中的概念、思路和方法，不行就看一下其他人的代碼（DDD DSL examples），也會(huì)幫助你很快學(xué)習(xí)，掌握這些方法論，回頭你再使用圖書和文章進(jìn)行鞏固一下，也是非常好的。

作者：茶什！

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載

總結(jié)

以上是生活随笔為你收集整理的DDD as Code：如何用代码诠释领域驱动设计？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。