DDD由來(lái)與優(yōu)勢(shì)

軟件架構(gòu)設(shè)計(jì)的真正目的是解決軟件復(fù)雜度帶來(lái)的問(wèn)題菠镇，軟件復(fù)雜度由來(lái)主要由三方面：高并發(fā)場(chǎng)景下的對(duì)軟件高性能要求、業(yè)務(wù)場(chǎng)景對(duì)軟件高可用要求沉填、持續(xù)變化的業(yè)務(wù)以及業(yè)務(wù)擴(kuò)張和增加需求對(duì)軟件擴(kuò)展性的要求芙代，除此外，對(duì)低成本央勒、安全、軟件規(guī)模也一定程度上增加了軟件設(shè)計(jì)的復(fù)雜度澳化。

在解決每個(gè)復(fù)雜度維度上崔步，分別有各自的應(yīng)對(duì)解決方案：

在高性能方面，可以通過(guò)單機(jī)和集群兩個(gè)維度提升系統(tǒng)性能：在單機(jī)方面通過(guò)多進(jìn)程缎谷、多線程等技術(shù)解決單機(jī)高并發(fā)井濒，在集群方面通過(guò)任務(wù)拆解灶似、分解，將任務(wù)調(diào)度到每個(gè)Worker節(jié)點(diǎn)執(zhí)行瑞你，從而進(jìn)一步提升系統(tǒng)整體高并發(fā)與吞吐量

在高可用方面酪惭，可以通過(guò)冗余服務(wù)或機(jī)器節(jié)點(diǎn)方式來(lái)確保整體應(yīng)用的高可用，常見的有計(jì)算和存儲(chǔ)高可用(如Mysql主從集群)者甲，而高可用的狀態(tài)決策是非常關(guān)鍵的一點(diǎn)春感，即是否由一個(gè)狀態(tài)轉(zhuǎn)移到另一個(gè)狀態(tài)，常見決策方式有獨(dú)裁虏缸、協(xié)商(如redis哨兵鲫懒、主備切換）、民主（如Paxos刽辙、Raft等分布式一致性算法）

在擴(kuò)展性方面窥岩，由于軟件唯一不變就是變化這個(gè)基本定理存在，正確的預(yù)測(cè)變化宰缤、完美封裝變化颂翼，本身就是一件復(fù)雜事情；在這點(diǎn)上慨灭，才有把變化封裝起來(lái)朦乏，與穩(wěn)定的不變內(nèi)容進(jìn)行隔離（分層、提升軟件內(nèi)聚性缘挑，降低耦合度）集歇，不變層通過(guò)接口去適配多變的情況（如文件系統(tǒng)的VFS適配多種文件格式，同時(shí)對(duì)用戶提供標(biāo)準(zhǔn)化的操作接口場(chǎng)景）

在低成本语淘、安全诲宇、規(guī)模方面，技術(shù)革命創(chuàng)新惶翻、功能和架構(gòu)安全姑蓝、軟件規(guī)模量變引發(fā)質(zhì)變（微服務(wù)就是典型例子），這些因素也增加了軟件的復(fù)雜度吕粗。

然而我們往往忽略了在軟件開發(fā)階段纺荧，因?yàn)樾枨蟮睦斫獠坏轿坏葘?dǎo)致的開發(fā)返工以及因?yàn)樵嚅_發(fā)人員離職帶來(lái)的交接文檔的缺失，導(dǎo)致新人接手項(xiàng)目的高上手成本颅筋、高溝通成本和高維護(hù)成本宙暇。是否存在有效的方法能夠在開發(fā)人員開始編碼之前能解決這一問(wèn)題呢？

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain Driven Desing议泵，簡(jiǎn)稱DDD）就是在可擴(kuò)展性方面將復(fù)雜多變的業(yè)務(wù)排除在穩(wěn)定不變的內(nèi)核業(yè)務(wù)之外占贫，從而在多變的環(huán)境中找到不變的部分，達(dá)到以不變應(yīng)萬(wàn)變的目標(biāo)先口。不僅如此型奥，DDD還能夠以更優(yōu)于靜態(tài)文檔的方式提供開發(fā)人員瞳收，業(yè)務(wù)人員所需要的業(yè)務(wù)知識(shí)，因?yàn)镈DD在設(shè)計(jì)之初就要求業(yè)務(wù)人員特別是領(lǐng)域?qū)＜遗c開發(fā)人員通過(guò)雙方統(tǒng)一的語(yǔ)言一起來(lái)協(xié)作設(shè)計(jì)系統(tǒng)厢汹，最終交付給業(yè)務(wù)人員能夠“讀”得懂的螟深，符合其期望的產(chǎn)品，盡管這一愿望很激動(dòng)人心烫葬，但實(shí)施過(guò)程并不順利界弧，但無(wú)論如何我們也應(yīng)該堅(jiān)持這一目標(biāo)，就像DDD作者總結(jié)的那樣厘灼，會(huì)給整個(gè)團(tuán)隊(duì)甚至公司帶來(lái)的益處遠(yuǎn)超過(guò)因?yàn)閷W(xué)習(xí)DDD帶來(lái)的成本夹纫，這些優(yōu)勢(shì)歸結(jié)起來(lái)如是：

? 使領(lǐng)域?qū)＜液烷_發(fā)者在一起密切合作，這樣開發(fā)出來(lái)的軟件能夠準(zhǔn)確地傳達(dá)業(yè)務(wù)規(guī)則设凹。“準(zhǔn)確傳達(dá)業(yè)務(wù)規(guī)則”的意思是說(shuō)茅姜，此時(shí)的軟件就像是領(lǐng)域?qū)＜宜_發(fā)出來(lái)的一樣闪朱。

? 可以幫助業(yè)務(wù)人員自我提高。沒(méi)有任何一個(gè)領(lǐng)域?qū)＜一蛘吖芾碚吒艺f(shuō)他對(duì)業(yè)務(wù)已經(jīng)了如指掌了钻洒，業(yè)務(wù)知識(shí)也需要一個(gè)長(zhǎng)期的學(xué)習(xí)過(guò)程奋姿。在DDD中，每個(gè)人都在學(xué)習(xí)素标，同時(shí)每個(gè)人又是知識(shí)的貢獻(xiàn)者称诗。

? 關(guān)鍵在于對(duì)知識(shí)的集中，因?yàn)檫@樣可以確保軟件知識(shí)并不只是掌握在少數(shù)人手中头遭。

? 在領(lǐng)域?qū)＜以⒚狻㈤_發(fā)者和軟件本身之間不存在“翻譯”，意思是當(dāng)大家都使用相同的語(yǔ)言進(jìn)行交流時(shí)计维，每人都能聽懂他人所說(shuō)袜香。

? 設(shè)計(jì)就是代碼，代碼就是設(shè)計(jì)鲫惶。設(shè)計(jì)是關(guān)于軟件如何工作的蜈首，最好的編碼設(shè)計(jì)來(lái)自于多次試驗(yàn)，這得益于敏捷的發(fā)現(xiàn)過(guò)程欠母。

? DDD同時(shí)提供了戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)兩種方式欢策。戰(zhàn)略設(shè)計(jì)幫助我們理解哪些投入是最重要的；哪些既有軟件資產(chǎn)是可以重新拿來(lái)使用的赏淌；哪些人應(yīng)該被加到團(tuán)隊(duì)中踩寇？戰(zhàn)術(shù)設(shè)計(jì)則幫助我們創(chuàng)建DDD模型中各個(gè)部件。

就像其他高回報(bào)率的投入一樣猜敢，DDD需要我們?cè)跁r(shí)間和精力上都有所投入姑荷。但是盒延，考慮到我們?cè)陂_發(fā)軟件的過(guò)程中經(jīng)常遇到的各種問(wèn)題和挑戰(zhàn)，這樣的投入是值得的鼠冕。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)分層架構(gòu)

分層架構(gòu)模式被認(rèn)為是所有架構(gòu)的始祖添寺。在自然界中，大到宇宙天體懈费，小到原子的運(yùn)行模式计露。在人類社會(huì)中，大到國(guó)際組織憎乙，小到團(tuán)體的組織模式票罐，都采用層次結(jié)構(gòu)。在軟件架構(gòu)中泞边，從早期的網(wǎng)絡(luò)七層協(xié)議该押，操作系統(tǒng)的內(nèi)核架構(gòu)到廣泛使用的MVC軟件開發(fā)架構(gòu)，都在使用分層架構(gòu)阵谚，可見分層模式經(jīng)久不衰蚕礼。 分層架構(gòu)的好處是顯而易見的，首先梢什，由于層間松散的耦合關(guān)系奠蹬，使得我們可以專注于本層的設(shè)計(jì)，而不必關(guān)心其他層的設(shè)計(jì)嗡午，也不必?fù)?dān)心自己的設(shè)計(jì)會(huì)影響其它層囤躁，對(duì)提高軟件質(zhì)量大有裨益。其次荔睹，分層架構(gòu)使得程序結(jié)構(gòu)清晰狸演，升級(jí)和維護(hù)都變得十分容易，更改某層的具體實(shí)現(xiàn)代碼应媚，只要本層的接口保持穩(wěn)定严沥，其他層可以不必修改。即使本層的接口發(fā)生變化中姜，也只影響相鄰的上層消玄，修改工作量小且錯(cuò)誤可以控制，不會(huì)帶來(lái)意外的風(fēng)險(xiǎn)丢胚。 分層架構(gòu)的一個(gè)重要原則是每層只能與位于其下方的層發(fā)生耦合翩瓜。分層架構(gòu)可以簡(jiǎn)單分為兩種，即嚴(yán)格分層架構(gòu)和松散分層架構(gòu)携龟。在嚴(yán)格分層架構(gòu)中兔跌，某層只能與位于其直接下方的層發(fā)生耦合，而在松散分層架構(gòu)中峡蟋，則允許某層與它的任意下方層發(fā)生耦合坟桅。

下圖A中所示為一個(gè)典型的DDD系統(tǒng)所采用的傳統(tǒng)分層架構(gòu)华望，其中核心域只位于架構(gòu)中的其中一層，其上為用戶界面層（User Interface）和應(yīng)用層（Application Layer）仅乓，其下是基礎(chǔ)設(shè)施層（Infrastructure Layer）赖舟。

User Interface為用戶界面層（或表示層）财搁，負(fù)責(zé)向用戶顯示信息和解釋命令商架，業(yè)務(wù)邏輯僅僅是有關(guān)輸入?yún)?shù)驗(yàn)證等的驗(yàn)證等步责，不同于領(lǐng)域?qū)拥臉I(yè)務(wù)邏輯熙暴。這里指的用戶可以是另一個(gè)計(jì)算機(jī)系統(tǒng)，不一定是使用用戶界面的人遭赂。

Application為應(yīng)用層缀雳，定義軟件要完成的任務(wù)题诵，并且指揮表達(dá)領(lǐng)域概念的對(duì)象來(lái)解決問(wèn)題紧显。這一層所負(fù)責(zé)的工作對(duì)業(yè)務(wù)來(lái)說(shuō)意義重大讲衫，也是與其它系統(tǒng)的應(yīng)用層進(jìn)行交互的必要渠道。應(yīng)用層要盡量簡(jiǎn)單鸟妙，不包含業(yè)務(wù)規(guī)則或者知識(shí)焦人，而只為下一層中的領(lǐng)域?qū)ο髤f(xié)調(diào)任務(wù)，分配工作重父，使它們互相協(xié)作。 當(dāng)需要?jiǎng)?chuàng)建新的聚合時(shí)忽匈，應(yīng)用服務(wù)應(yīng)該使用工廠或聚合的構(gòu)造函數(shù)來(lái)實(shí)例化對(duì)象房午，然后采用資源庫(kù)對(duì)其進(jìn)行持久化。應(yīng)用服務(wù)還可以調(diào)用領(lǐng)域服務(wù)來(lái)完成和領(lǐng)域相關(guān)的任務(wù)操作丹允，但此時(shí)的操作應(yīng)該是無(wú)狀態(tài)的郭厌。當(dāng)領(lǐng)域模型用于發(fā)布領(lǐng)域事件時(shí)，應(yīng)用層可以將訂閱方注冊(cè)到任意數(shù)量的事件上雕蔽，這樣的好處是可以對(duì)事件進(jìn)行存儲(chǔ)和轉(zhuǎn)發(fā)折柠。同時(shí)，領(lǐng)域模型只需要關(guān)注自己的核心邏輯批狐；領(lǐng)域事件發(fā)布器也可以保持輕量化扇售，而不用依賴于消息機(jī)制的基礎(chǔ)設(shè)施。

Domain為領(lǐng)域?qū)樱ɑ蚰Ｐ蛯樱┫В?fù)責(zé)表達(dá)業(yè)務(wù)概念承冰，業(yè)務(wù)狀態(tài)信息以及業(yè)務(wù)規(guī)則。盡管保存業(yè)務(wù)狀態(tài)的技術(shù)細(xì)節(jié)是由基礎(chǔ)設(shè)施層實(shí)現(xiàn)的食零，但是反映業(yè)務(wù)情況的狀態(tài)是由本層控制并且使用的困乒。領(lǐng)域?qū)邮菢I(yè)務(wù)軟件的核心，領(lǐng)域模型位于這一層贰谣。

Infrastructure層為基礎(chǔ)設(shè)施層娜搂，向其他層提供通用的技術(shù)能力：為應(yīng)用層傳遞消息迁霎，為領(lǐng)域?qū)犹峁┏志没瘷C(jī)制，為用戶界面層繪制屏幕組件等百宇，其中消息包含了消息中間件所發(fā)的消息考廉、基本的電子郵件（SMTP）或者文本消息（SMS）等

但是分層架構(gòu)也不是沒(méi)有缺點(diǎn)，除了引入分層導(dǎo)致層之間交互帶來(lái)的性能開銷之外恳谎，也存在一些開發(fā)上的問(wèn)題芝此，比如：

1）容易導(dǎo)致分層劃分不當(dāng)，比如領(lǐng)域邏輯大量滲透到應(yīng)用服務(wù)層因痛，導(dǎo)致領(lǐng)域模型變成貧血模型婚苹，盡管有些最佳實(shí)踐和其他解決方案能夠解決上述問(wèn)題，但也增大了新方案帶來(lái)的學(xué)習(xí)成本

2）容易違反分層架構(gòu)原則鸵膏，比如在DDD設(shè)計(jì)中膊升，如果領(lǐng)域?qū)邮褂昧嘶A(chǔ)設(shè)施層的實(shí)體對(duì)象持久化機(jī)制，那么基礎(chǔ)設(shè)施層將反向引用領(lǐng)域?qū)拥臉I(yè)務(wù)對(duì)象谭企，違反了分層架構(gòu)原則廓译。即使領(lǐng)域?qū)邮褂没A(chǔ)設(shè)施層的持久化庫(kù)接口Repository，領(lǐng)域模型仍然存在外部依賴债查，無(wú)法保證業(yè)務(wù)邏輯的順利執(zhí)行非区，也給測(cè)試開發(fā)帶來(lái)了困難，理想中的領(lǐng)域模型應(yīng)該是純業(yè)務(wù)盹廷、基于內(nèi)存運(yùn)行的業(yè)務(wù)邏輯封裝征绸。

對(duì)第一個(gè)問(wèn)題，可以通過(guò)DCI來(lái)解決俄占，詳見下文#DDD與DCI部分管怠。對(duì)第二個(gè)問(wèn)題可以通過(guò)依賴倒置原則(Dependency Inversion Principle,DIP)來(lái)解決，詳見下文#DDD與六邊形架構(gòu)部分

DDD與DCI

面向?qū)ο蠼Ｃ媾R的一個(gè)棘手問(wèn)題是數(shù)據(jù)邊界和行為邊界往往不一致缸榄。遵循模塊化的思想渤弛，我們通過(guò)類將行為和其緊密耦合的數(shù)據(jù)封裝在一起。但是在復(fù)雜的業(yè)務(wù)場(chǎng)景下甚带，行為往往跨越多個(gè)領(lǐng)域?qū)ο笏希@樣的行為如果放在某一個(gè)對(duì)象中必然會(huì)導(dǎo)致別的對(duì)象需要向該對(duì)象暴漏其內(nèi)部狀態(tài)。所以面向?qū)ο蟀l(fā)展的后來(lái)欲低，領(lǐng)域建模出現(xiàn)兩種派別之爭(zhēng)辕宏，一種傾向于將跨越多個(gè)領(lǐng)域?qū)ο蟮男袨榻Ｔ陬I(lǐng)域服務(wù)中。如果這種做法使用過(guò)度砾莱，則會(huì)導(dǎo)致領(lǐng)域?qū)ο笞兂芍惶峁┮欢裧et方法的啞對(duì)象瑞筐，這種建模結(jié)果被稱之為貧血模型。而另一派則堅(jiān)定地認(rèn)為方法應(yīng)該屬于領(lǐng)域?qū)ο螅运械臉I(yè)務(wù)行為仍然被放在領(lǐng)域?qū)ο笾芯奂伲@樣導(dǎo)致領(lǐng)域?qū)ο箅S著支持的業(yè)務(wù)場(chǎng)景變多而變成上帝類块蚌，而且類內(nèi)部方法的抽象層次很難一致。另外由于行為邊界很難恰當(dāng)膘格，導(dǎo)致對(duì)象之間數(shù)據(jù)訪問(wèn)關(guān)系也比較復(fù)雜峭范，這種建模結(jié)果被稱之為充血模型。

比如以字處理器中拼音檢查為例瘪贱，拼音檢查這個(gè)行為功能放在哪里纱控？是dictionary 還是一個(gè)全局的拼音檢查器呢？無(wú)論放在哪個(gè)對(duì)象內(nèi)部菜秦，都顯得和這個(gè)對(duì)象內(nèi)聚性不高甜害，由此帶來(lái)多個(gè)調(diào)用拼音檢查行為對(duì)象之間的協(xié)作耦合，在DDD 中球昨，可以使用領(lǐng)服務(wù)來(lái)實(shí)現(xiàn)尔店；在SOA看來(lái)，拼音檢查屬于一種規(guī)則主慰，可由規(guī)則引擎實(shí)現(xiàn)嚣州，通過(guò)服務(wù)整合流程和規(guī)則。

再比如銀行轉(zhuǎn)賬共螺，如果將轉(zhuǎn)賬的業(yè)務(wù)邏輯這個(gè)程序算法整合到賬戶Account數(shù)據(jù)模型中该肴，因?yàn)檗D(zhuǎn)賬涉及到其他賬戶和Money數(shù)據(jù)對(duì)象，那么就將因?yàn)樾袨椴僮鲙?lái)的耦合帶到當(dāng)前賬戶對(duì)象中了藐不；當(dāng)然沙庐，如果程序算法可以精化細(xì)分，那么我們把它切分到幾個(gè)部分佳吞，封裝成幾個(gè)對(duì)象的方法，但是這些方法都是無(wú)法表達(dá)算法邏輯高內(nèi)聚性的瑣碎小方法棉安。

DCI架構(gòu)則不同于DDD 這種有些折扣的處理方法底扳，而是思路復(fù)位，重新考慮架構(gòu)贡耽。DCI架構(gòu)是James O. Coplien和Trygve Reenskaug在2009年發(fā)表的論文《Architecture: A New Vision of Object-Oriented Programming》(以下簡(jiǎn)稱DCI Architecture）中引入衷模，從OO 思想根源來(lái)深入解剖DCI 對(duì)傳統(tǒng)面向?qū)ο蟮念嵏病CI從對(duì)象數(shù)據(jù)object Data, 對(duì)象之間的協(xié)作the Collaborations between objects, 和表達(dá)需求用例中操作者角色之間的交互這三個(gè)出發(fā)點(diǎn)來(lái)考慮蒲赂，認(rèn)為數(shù)據(jù)模型data model, 角色模型role model和協(xié)作交互模型collaboration model(算法屬于協(xié)作交互模型) 應(yīng)該是程序語(yǔ)言核心關(guān)心點(diǎn)阱冶，應(yīng)該從語(yǔ)言層面來(lái)關(guān)注，DCI各部分組成及含義如下：

Data：描述系統(tǒng)有哪些領(lǐng)域概念及其之間的關(guān)系滥嘴，該層專注于領(lǐng)域?qū)ο蟮拇_立和這些對(duì)象的生命周期管理及關(guān)系木蹬，讓程序員站在對(duì)象的角度思考系統(tǒng)

Context：Context通過(guò)無(wú)狀態(tài)綁定role來(lái)完成業(yè)務(wù)邏輯，提供理解軟件業(yè)務(wù)流程的切入點(diǎn)和主線

Interaction： 主要體現(xiàn)在對(duì)role的建模若皱，role是每個(gè)context中復(fù)雜的業(yè)務(wù)邏輯的真正執(zhí)行者镊叁。role所做的是對(duì)行為進(jìn)行建模尘颓，它連接了context和領(lǐng)域?qū)ο蟆Ｓ捎谙到y(tǒng)的行為是復(fù)雜且多變的晦譬，role使得系統(tǒng)將穩(wěn)定的領(lǐng)域模型層和多變的系統(tǒng)行為層進(jìn)行了分離疤苹，由role專注于對(duì)系統(tǒng)行為進(jìn)行建模。

DCI目前廣泛被看作是對(duì)DDD的一種發(fā)展和補(bǔ)充敛腌，用在基于面向?qū)ο蟮念I(lǐng)域建模上卧土。顯式的對(duì)role進(jìn)行建模，解決了面向?qū)ο蠼Ｖ械某溲Ｐ秃拓氀Ｐ椭疇?zhēng)像樊。DCI通過(guò)顯式的用role對(duì)行為進(jìn)行建模尤莺，同時(shí)讓role在context中可以和對(duì)應(yīng)的領(lǐng)域?qū)ο筮M(jìn)行綁定(cast)，從而既解決了數(shù)據(jù)邊界和行為邊界不一致的問(wèn)題凶硅，也解決了領(lǐng)域?qū)ο笾袛?shù)據(jù)和行為高內(nèi)聚低耦合的問(wèn)題缝裁。跟DDD將對(duì)象和行為靜態(tài)結(jié)合不同，DCI結(jié)合上下文將role代表的行為和對(duì)象動(dòng)態(tài)結(jié)合足绅。

DDD與六邊形架構(gòu)

依賴倒置原則由Robert C. Martin提出捷绑，正式定義為：

高層模塊不應(yīng)該依賴于底層模塊，兩者都應(yīng)該依賴于抽象氢妈。

抽象不應(yīng)該依賴于細(xì)節(jié)粹污，細(xì)節(jié)應(yīng)該依賴于抽象。

根據(jù)該定義首量，DDD分層架構(gòu)中的低層組件應(yīng)該依賴于高層組件提供的接口壮吩，即無(wú)論高層還是低層都依賴于抽象，我們將原來(lái)位于底層的基礎(chǔ)設(shè)施層調(diào)整到最高層加缘，然后依賴下面各層提供的抽象接口鸭叙，那么就解決了之前基礎(chǔ)設(shè)施層反向依賴領(lǐng)域?qū)拥膯?wèn)題，同時(shí)原來(lái)的領(lǐng)域?qū)游挥谧畹讓蛹鸷辏辉侔志没壬虮矗P(guān)于可測(cè)試性問(wèn)題也迎刃而解，調(diào)整后的層次結(jié)構(gòu)如上圖B所示勋乾。

上面只是采用依賴倒置原則實(shí)現(xiàn)的一種架構(gòu)表現(xiàn)宋下，因?yàn)橐蕾嚨怪迷瓌t要求所有層次都依賴抽象，這就意味著層次可以“平等相處”辑莫，已經(jīng)失去存在的必要学歧，這時(shí)的層次架構(gòu)如同在依賴倒置原則的“重力效應(yīng)”下瞬間坍縮一樣，形成下圖所示的一種具有對(duì)稱性特征的架構(gòu)風(fēng)格各吨，即六邊形架構(gòu)：

六邊形架構(gòu)也叫端口和適配器架構(gòu)枝笨，是Alistair Cockburn于2005年在其博客中提出。他對(duì)該架構(gòu)的一句話定義是：應(yīng)用應(yīng)能平等地被用戶、其他程序伺帘、自動(dòng)化測(cè)試或腳本驅(qū)動(dòng)昭躺，也可以獨(dú)立于其最終的運(yùn)行時(shí)設(shè)備和數(shù)據(jù)庫(kù)進(jìn)行開發(fā)和測(cè)試。該架構(gòu)由端口和適配器組成伪嫁，所謂端口是應(yīng)用的入口和出口领炫，在許多語(yǔ)言中，它以接口的形式存在张咳。例如以取消訂單為例帝洪，“發(fā)送訂單取消通知”可以被認(rèn)為是一個(gè)出口端口，訂單取消的業(yè)務(wù)邏輯決定了何時(shí)調(diào)用該端口脚猾，訂單信息決定了端口的輸入葱峡，而端口為預(yù)訂流程屏蔽了通知發(fā)送方式的實(shí)現(xiàn)細(xì)節(jié)。

而適配器分為兩種龙助，主適配器（別名Driving Adapter）代表用戶如何使用應(yīng)用砰奕，從技術(shù)上來(lái)說(shuō)，它們接收用戶輸入提鸟，調(diào)用端口并返回輸出军援。Rest API是目前最常見的應(yīng)用使用方式，以取消訂單為例称勋，該適配器實(shí)現(xiàn)Rest API的Endpoint胸哥，并調(diào)用入口端口CancelOrderService。同一個(gè)端口可能被多種適配器調(diào)用赡鲜，例如CancelOrderService也可能會(huì)被實(shí)現(xiàn)消息協(xié)議的Driving Adapter調(diào)用以便異步取消訂單空厌。

次適配器（別名Driven Adapter）實(shí)現(xiàn)應(yīng)用的出口端口，向外部工具執(zhí)行操作银酬，例如

向MySQL執(zhí)行SQL嘲更，存儲(chǔ)訂單

使用Elasticsearch的API搜索產(chǎn)品

使用郵件/短信發(fā)送訂單取消通知

若將其可視化，Driving Adapter和Driven Adapter基于端口圍繞著應(yīng)用和域形成左右結(jié)構(gòu)：

其中值得注意的是揩瞪，中間核心區(qū)的業(yè)務(wù)邏輯是由Application和Domain組成哮内，即由分層架構(gòu)中的應(yīng)用層和領(lǐng)域?qū)雍喜⒍鴣?lái)。圖例中的Controller壮韭、Listener和Template是北向適配器（Driving Adapter），JPARepository纹因、EventPublisher喷屋、DomainService是南向適配器（Driven Adapter），業(yè)務(wù)邏輯核心區(qū)中的不同Application Service組成不同的端口瞭恰。如果將六邊形架構(gòu)和傳統(tǒng)的分層架構(gòu)做個(gè)對(duì)比屯曹，那就是：

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)要素

在DDD中，軟件的核心是其為客戶解決領(lǐng)域相關(guān)的問(wèn)題的能力。這里的領(lǐng)域恶耽，就是指軟件系統(tǒng)要解決的實(shí)際問(wèn)題相關(guān)的東西的集合密任。例如：為一個(gè)電子商務(wù)公司開發(fā)一個(gè)電商系統(tǒng)，我們就需要圍繞這個(gè)盈利模式的運(yùn)營(yíng)方式偷俭、業(yè)務(wù)規(guī)則浪讳，比如如何進(jìn)貨，如何促銷涌萤，如何物流等等了解這個(gè)電子商務(wù)公司的盈利模式淹遵，所有和業(yè)務(wù)相關(guān)的東西都屬于領(lǐng)域。領(lǐng)域分為問(wèn)題域和解決方案域兩部分负溪。

為了分解問(wèn)題域的復(fù)雜度透揣，問(wèn)題域又會(huì)被拆解為多個(gè)子域，每個(gè)子域都要明確待解決的業(yè)務(wù)問(wèn)題和業(yè)務(wù)流程川抡，以及通過(guò)解決業(yè)務(wù)問(wèn)題為企業(yè)帶來(lái)了什么樣的業(yè)務(wù)價(jià)值（這個(gè)是因辐真，業(yè)務(wù)流程和要解決的業(yè)務(wù)問(wèn)題是果）。

在清晰的定義子域后崖堤，我們就可以建立通用語(yǔ)言來(lái)提取該子域的領(lǐng)域知識(shí)侍咱，并基于通用語(yǔ)言為解決問(wèn)題建立領(lǐng)域模型。領(lǐng)域模型是關(guān)于某個(gè)特定業(yè)務(wù)領(lǐng)域的軟件模型倘感。通常放坏，領(lǐng)域模型通過(guò)對(duì)象模型來(lái)實(shí)現(xiàn)，這些對(duì)象同時(shí)包含了數(shù)據(jù)和行為老玛，并且表達(dá)了準(zhǔn)確的業(yè)務(wù)含義淤年。

一個(gè)領(lǐng)域模型會(huì)存在于一個(gè)限界上下文中。限界上下文在DDD中用來(lái)定義模型的適用范圍蜡豹、模型的用途麸粮、以及在何處保持一致，限界上下文會(huì)讓團(tuán)隊(duì)明確模型的職責(zé)邊界是什么镜廉。同時(shí)弄诲，通用語(yǔ)言被限定在限界上下文中；限界上下文提供了一個(gè)語(yǔ)義邊界娇唯，在每個(gè)限界上下文內(nèi)通用語(yǔ)言的每個(gè)詞匯必須和領(lǐng)域概念一一對(duì)應(yīng)齐遵。理想條件下，子域和限界上下文是一一對(duì)應(yīng)塔插。但是子域劃分的粒度梗摇，遺留系統(tǒng)的現(xiàn)狀，語(yǔ)言的歧義想许，團(tuán)隊(duì)結(jié)構(gòu)等子域和限界上下文對(duì)應(yīng)可能是1：N或者N：N的伶授。通過(guò)限界上下文間的映射断序，上下文中的多個(gè)模型會(huì)協(xié)作以滿足系統(tǒng)需求。我們也可以了解在不同上下文中的同名詞匯是否存在關(guān)系糜烹，存在什么樣的關(guān)系违诗。對(duì)通用語(yǔ)言而言，子域解釋了通用語(yǔ)言和現(xiàn)實(shí)世界業(yè)務(wù)活動(dòng)的關(guān)系疮蹦；限界上下文提供了一個(gè)語(yǔ)義邊界诸迟，來(lái)保持通用語(yǔ)言和領(lǐng)域概念的一一對(duì)應(yīng)關(guān)系；上下文映射則提供了不同限界上下中的通用語(yǔ)言的轉(zhuǎn)換關(guān)系挚币。

DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)通常會(huì)包含戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)兩部分：

戰(zhàn)略設(shè)計(jì)：重業(yè)務(wù)建模亮蒋，以業(yè)務(wù)視角，拆分領(lǐng)域妆毕，通過(guò)事件風(fēng)暴（從發(fā)散到收斂過(guò)程）慎玖，梳理業(yè)務(wù)并構(gòu)建領(lǐng)域模型，這塊過(guò)程會(huì)涉及業(yè)務(wù)人員笛粘、產(chǎn)品人員援所、架構(gòu)師等多方參與

戰(zhàn)術(shù)設(shè)計(jì)：重落地實(shí)現(xiàn)致盟，以構(gòu)建的領(lǐng)域模型律胀，建立了領(lǐng)域模型的邊界與上下文柴淘，也就確認(rèn)了微服務(wù)的邊界，這個(gè)過(guò)程會(huì)涉及架構(gòu)師示括、技術(shù)人員參與

下面的圖展示了DDD設(shè)計(jì)開發(fā)的一般步驟和涉及到的戰(zhàn)略設(shè)計(jì)和戰(zhàn)術(shù)設(shè)計(jì)相關(guān)的概念與要素：

原型與4色原型建模法

在接手一個(gè)新的業(yè)務(wù)需求铺浇，首先要明確業(yè)務(wù)邊界和要解決的問(wèn)題，然后通過(guò)一種方法將業(yè)務(wù)活動(dòng)涉及到的各種要素進(jìn)行分解垛膝，抽象出原型鳍侣，然后描述各原型之間的協(xié)作方式，通過(guò)UML類圖的形式可視化呈現(xiàn)出來(lái)吼拥。最后跟業(yè)務(wù)人員和領(lǐng)域?qū)＜乙黄饏f(xié)作完善倚聚，保證最后開發(fā)的系統(tǒng)能體現(xiàn)業(yè)務(wù)方的需求。

原型一詞來(lái)自于希臘語(yǔ)archetypo (arcetupo), 意味著 "original pattern." （原始模式）凿可。 比如英雄這個(gè)原型在美國(guó)或在中國(guó)看上去可能不一樣惑折，但是英雄就是英雄，我們還是能夠很快地總結(jié)出英雄的一些特點(diǎn)枯跑。 因?yàn)樵褪侨祟惤M織惨驶、總結(jié)和概括客觀世界的基本概念，我們完全有理由在軟件開發(fā)領(lǐng)域應(yīng)用這些概念敛助。

OO軟件系統(tǒng)是對(duì)業(yè)務(wù)領(lǐng)域（business domain）的思考抽象并進(jìn)行管理操作敞咧，注意業(yè)務(wù)領(lǐng)域這個(gè)概念，我們相信應(yīng)該能在業(yè)務(wù)領(lǐng)域中發(fā)現(xiàn)原型辜腺，或者在軟件系統(tǒng)休建；或者這些系統(tǒng)模型中。我們稱這種原型類型為業(yè)務(wù)原型（business archetype）

一個(gè)業(yè)務(wù)原型應(yīng)該是一個(gè)在業(yè)務(wù)領(lǐng)域或商業(yè)軟件系統(tǒng)持續(xù)發(fā)生并且普遍存在的最初級(jí)的事物评疗。參與方Party是一個(gè)業(yè)務(wù)原型例子测砂，一個(gè)Party代表可標(biāo)識(shí)的、可定位的單元或單位百匆，這些單位有正常的狀態(tài)砌些。通常一個(gè)Party用來(lái)表示某個(gè)人或某個(gè)組織。所有商業(yè)系統(tǒng)都或多或少有Party概念加匈。

原型之間是相互交互的存璃，Party, Product和Order是每個(gè)虛擬商業(yè)系統(tǒng)的基本概念，在這個(gè)商業(yè)系統(tǒng)中雕拼，你可以賣產(chǎn)品或服務(wù)纵东。我們將這些原型之間的協(xié)作看成是業(yè)務(wù)原型模式(business archetype patterns)：它是在業(yè)務(wù)領(lǐng)域或商業(yè)軟件系統(tǒng)持續(xù)發(fā)生并且普遍存在業(yè)務(wù)原型之間的協(xié)作。

四色原型是誕生于90年代啥寇，被廣泛使用的一種系統(tǒng)分析方法偎球，在域建模階段，將4種不同的業(yè)務(wù)原型按照不同的顏色標(biāo)出辑甜。這4種原型分別為：

時(shí)刻-時(shí)段原型（Moment-Interval Archetype衰絮，簡(jiǎn)稱MI）：一段時(shí)間內(nèi)發(fā)生的業(yè)務(wù)，包括與業(yè)務(wù)相關(guān)的數(shù)據(jù)以及行為磷醋。數(shù)據(jù)及行為是可以追蹤的猫牡，如賣東西是在某個(gè)時(shí)刻發(fā)生的，它有發(fā)生日期和時(shí)間等相關(guān)記錄信息邓线。時(shí)刻-時(shí)段原型使用粉紅顏色表示淌友。

角色原型（Role Archetype）：任何一個(gè)系統(tǒng)都需要人或某個(gè)組織介入運(yùn)行，例如論壇系統(tǒng)需要注冊(cè)者角色發(fā)言褂痰；銷售訂單需要業(yè)務(wù)員角色制定等亩进。角色模型使用黃色標(biāo)識(shí)。

參與方-地點(diǎn)-物品原型（Part-Place-Thing Archetype缩歪，簡(jiǎn)稱PPT）：表示參與扮演不同角色的參與方或地點(diǎn)或事物归薛。Party表示有自己正常的狀態(tài)并且能夠自主控制自己的一些行為，如人或組織匪蝙， place, or thing表示沒(méi)有自主行為主籍，如某個(gè)地方或某個(gè)事情。Part-Place-Thing都可以成為角色逛球，也就是通過(guò)扮演角色參與活動(dòng)千元。如商品可以是售賣中的商品也可以是使用中的商品，可以在不同場(chǎng)景扮演不同的角色颤绕。參與方-地點(diǎn)-物品原型使用綠色表示幸海。

描述原型（Description Archetype祟身，簡(jiǎn)稱DESC）：Desc是對(duì)PPT的抽象概念，它是PPT的特性的總結(jié)物独，每一個(gè)PPT都屬于一個(gè)（種）Desc袜硫。比如每一臺(tái)出廠的車輛都屬于車輛種類的一輛，每一個(gè)具體的人都屬于人種的一員挡篓。PPT原型是對(duì)單個(gè)個(gè)體的抽象婉陷，比如一輛具體的轎車可以用車輛編號(hào)、車輛顏色官研、車輛型號(hào)等描述秽澳，一個(gè)人可以用身份證號(hào)碼、身高戏羽、體重担神、喜好來(lái)描述。而對(duì)車輛種類的抽象描述為生產(chǎn)廠家蛛壳、生產(chǎn)批號(hào)杏瞻、適用顏色等等，當(dāng)然轎車種類通常還可以劃分為微型轎車衙荐、普通轎車捞挥、高級(jí)轎車等。同理對(duì)于人種包含歐羅巴人種（又稱白色人種或高加索人種或歐亞人種）忧吟、蒙古人種（又稱黃色人種或亞美人種）砌函、尼格羅人種（又稱黑色人種或赤道人種），對(duì)于人種的描述可以是膚色溜族、地獄分布讹俊、主要使用語(yǔ)言等。描述原型用藍(lán)色表示煌抒。

4色原型是對(duì)物理世界的建模方式仍劈，如果以PPT為中心，那么以上概念可以總結(jié)為：什么東西（人或事物）在什么地方通過(guò)什么方式（角色）在什么時(shí)刻進(jìn)行操作寡壮，類似于5W2H分析法贩疙。4色原型的一個(gè)直接好處是幫助我們快速地梳理不同的業(yè)務(wù)原型，通過(guò)類圖的方式繪畫不同原型及其之間的關(guān)系况既，在實(shí)際建模過(guò)程中可以采取以下步驟分辨不同原型：

第一：它是不是依賴時(shí)間長(zhǎng)瞬間或一段短時(shí)間存在的这溅，是不是業(yè)務(wù)需求需要跟蹤記錄的對(duì)象？如果是棒仍，它就是MI原型悲靴。

第二：它是不是角色呢？如果是莫其，就屬于黃色Role原型癞尚。

第三：它是不是屬于一種種類性質(zhì)對(duì)象耸三，或者代表一組可以反復(fù)使用的概念，如果是浇揩，它就是藍(lán)色Description原型吕晌。

第四：它是某人或組織？或者是某個(gè)地方或者某個(gè)東西临燃？那它就是綠色的PPT原型。

下文通過(guò)實(shí)際案例結(jié)合5W2H分析法和四色原型法來(lái)描述DDD建模過(guò)程烙心。

DDD建模案例

燃?xì)獬碛?jì)費(fèi)場(chǎng)景每月末膜廊，燃?xì)夤局贫ǔ碛?jì)劃并批量生成抄表任務(wù)，抄表任務(wù)通過(guò)工單的形式下發(fā)到抄表人員到客戶現(xiàn)場(chǎng)抄表淫茵，抄表完成之后給客戶應(yīng)收賬單爪瓜，客戶可以現(xiàn)場(chǎng)繳費(fèi)或者延后通過(guò)在線自助繳費(fèi)。下面以此案例描述建模步驟匙瘪。

1 描述業(yè)務(wù)場(chǎng)景

用5W2H進(jìn)行分析：用戶（WHO）在什么環(huán)境（WHERE）下遇到什么時(shí)機(jī)（WHEN）因?yàn)槭裁矗╓HY）產(chǎn)生什么目標(biāo)（WHAT）铆铆，繼而通過(guò)什么方法（HOW）去達(dá)成目標(biāo)。大部分場(chǎng)景不需要考慮HOW MUCH丹喻。

通過(guò)本案例的分析薄货，可以得到以下需求場(chǎng)景清單：

2 梳理業(yè)務(wù)流程

在得到場(chǎng)景清單后，我們把各個(gè)場(chǎng)景串聯(lián)起來(lái)用業(yè)務(wù)流程的方式表達(dá)出來(lái)：

3 尋找時(shí)標(biāo)性對(duì)象

時(shí)標(biāo)性對(duì)象對(duì)應(yīng)到時(shí)刻-時(shí)段原型碍论，是我們關(guān)心的可追溯的業(yè)務(wù)事件谅猾。通過(guò)將業(yè)務(wù)流程分解到業(yè)務(wù)過(guò)程的最小粒度來(lái)尋找，然后繪制以下格式的表格：

接著將這些時(shí)標(biāo)性對(duì)象（用紅色標(biāo)記）的關(guān)系描述出來(lái)鳍悠，就得到了領(lǐng)域模型的骨干：

4 尋找時(shí)標(biāo)對(duì)象周圍的“人税娜、地、物”

在“時(shí)標(biāo)”對(duì)象周圍的用綠色所表示的“人藏研、地敬矩、物”概念，如下圖所示：

5 抽象“角色”

在上圖中插入用黃色所表示的“角色”概念蠢挡，如下圖所示：

6 補(bǔ)充“描述”信息

在上圖中插入用藍(lán)色所表示的“描述”概念弧岳，描述對(duì)象包括“人、地袒哥、物”和時(shí)標(biāo)對(duì)象缩筛，如下圖所示：

7 劃分限界上下文

在本案例中，抄表繳費(fèi)屬于核心業(yè)務(wù)堡称，將業(yè)務(wù)過(guò)程中的時(shí)標(biāo)對(duì)象都劃分到核心子域瞎抛，但核心子域解決的問(wèn)題有所不同，比如抄表計(jì)劃和抄表任務(wù)指派屬于抄表前期規(guī)劃階段却紧，參與人員同其他階段都不同桐臊，因此將其劃分到計(jì)劃上下文胎撤。同樣，抄表記錄屬于抄表的實(shí)施階段断凶，劃分到抄表上下文伤提，繳費(fèi)屬于抄表后期階段，劃分到繳費(fèi)上下文认烁，如下圖：

8 確定聚合及聚合根

在每個(gè)上下文中肿男，對(duì)時(shí)標(biāo)對(duì)象中的概念按照相近原則劃分為不同的組，形成新的聚合却嗡，然后選出聚合根作為與外界交互的代表舶沛。比如抄表時(shí)標(biāo)對(duì)象產(chǎn)出的核心數(shù)據(jù)是待繳費(fèi)的應(yīng)收賬單，關(guān)聯(lián)對(duì)象涉及到抄表員窗价、客戶和表具如庭，而其他暫時(shí)無(wú)法分組的概念或?qū)傩元?dú)立為值對(duì)象，待需求需要的時(shí)候進(jìn)一步處理撼港。淺綠色代表聚合根坪它，下圖所示：

同理，繼續(xù)尋找其他上下文中的聚合和聚合根帝牡，如繳費(fèi)和支付：

注意上圖中支付和繳費(fèi)往毡、抄表都涉及到賬單聚合根，但是因?yàn)橘~單關(guān)注的點(diǎn)有所區(qū)別否灾，比如抄表關(guān)心的是應(yīng)收賬單卖擅，繳費(fèi)關(guān)心的是實(shí)收賬單，支付賬單關(guān)心的是無(wú)業(yè)務(wù)含義的交易流水和交易賬號(hào)墨技，不同關(guān)注點(diǎn)通過(guò)限界上下文隔離惩阶。

9 優(yōu)化調(diào)整子域劃分

通過(guò)聚合的過(guò)程我們發(fā)現(xiàn)，客戶和表具在多個(gè)上下文中共用扣汪，是可以將其獨(dú)立出來(lái)断楷，作為共享上下文，劃分到通用子域中崭别。另外冬筒，在繳費(fèi)環(huán)節(jié)，因?yàn)橹Ц锻ǔＷ鳛榛A(chǔ)功能茅主，支撐著繳費(fèi)等支付相關(guān)業(yè)務(wù)舞痰，因此也劃分到獨(dú)立的支撐子域，調(diào)整后的子域限界上下文如圖诀姚，其中虛線橢圓標(biāo)識(shí)的客戶响牛、表具屬于共享子域：

原文鏈接：

https://mp.weixin.qq.com/s?__biz=MzI3ODU3MzQ2Ng==&mid=2247484331&idx=1&sn=7da3e9a6f2e7acd5dd60eae574575dc9

如果覺(jué)得本文對(duì)你有幫助，就點(diǎn)贊關(guān)注支持一下吧！