初識DDD(DomainDrivenDesign)（二）：軟件架構(gòu)視角

本文將從軟件架構(gòu)角度，介紹DDD的分層架構(gòu)、組成要素、領(lǐng)域?qū)ο笊芷诠芾淼群诵母拍睢?/p>

10年積累的成都做網(wǎng)站、成都網(wǎng)站建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有故城免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

DDD（Domain Driven Design，領(lǐng)域驅(qū)動設(shè)計）核心是針對業(yè)務(wù)層建模的，但是為了保證業(yè)務(wù)層的相對獨立性，DDD從最佳實踐經(jīng)驗出發(fā)提出了下面的系統(tǒng)分層：

我們都知道分層結(jié)構(gòu)的好處。在Martin Fowler的著名的《Patterns of Enterprise Application Architecture》一書中有專門一章講分層（Layering）。上層單向調(diào)用下層，下層不應(yīng)該不知道上層；下層可以通過提供回調(diào)（callback,比如Observer模式、模板方法模式等）來注入上層的邏輯，但是下層還是不知道上層。如上面的DDD分層架構(gòu)圖。

各層的基本職責如下：

UI層：與常用的Presentation Tier類似，負責與客戶端交互、展示界面等。上圖也表示了UI層可以調(diào)用下面的任一層。
Application層：相當于一個Facade，是薄的一層。定義軟件要做的任務(wù)，協(xié)調(diào)和組織（coordinate）完成用戶請求需要的作業(yè)(tasks)并委托(delegate)給Domain層的調(diào)用。沒有業(yè)務(wù)邏輯（rules, knowledge）在里面。功能有點類似于企業(yè)級模式和J2EE模式Front Controller。
Domain層：業(yè)務(wù)軟件的核心。負責表示業(yè)務(wù)概念，業(yè)務(wù)狀況和業(yè)務(wù)規(guī)則。需要注意的是對業(yè)務(wù)狀態(tài)的保存（持久化）的技術(shù)細節(jié)不屬于這一層（不屬于業(yè)務(wù)模型），而要委托給Infrastructure層。在該層內(nèi)部，應(yīng)該采用Model Driven Design。
Infrastructure層：顧名思義，該層負責提供上面各層需要的通用性服務(wù)，如發(fā)送消息（Messaging）,領(lǐng)域?qū)ο蟮某志没?，提供繪制UI所需的Widget，提供各層通信所需框架等。

有了上面宏觀的分層框架之后，就可以進一步采用DDD的元素對一個初步的領(lǐng)域模型進行細化和實現(xiàn)了。

我們從基礎(chǔ)的四個元素或說概念說起：Entity，Value Object, Module, Association。Entity用來表示有Identity（俗稱ID）的領(lǐng)域?qū)ο?。Value Object用來表示沒有Identity的領(lǐng)域值對象。這些對象都帶有屬于領(lǐng)域?qū)ο蟮男袨?。Association表示他們之間的聯(lián)系。Module也可以叫Package，用來封裝概念上內(nèi)聚的一組DDD元素，表達一個具體的領(lǐng)域概念，相當于Java中的package。

需要注意的是DDD中的Entity與常見的基于SSH框架所做的系統(tǒng)中的Entity的區(qū)別。后者往往稱為貧血的業(yè)務(wù)對象（amemic domain object），因為它們只與持久化相關(guān)而沒有所屬的業(yè)務(wù)行為，只有g(shù)etter/setter之類的基本方法。相應(yīng)地那些業(yè)務(wù)行為移到了"Service"中。于是Service（或者ServiceImpl）中出現(xiàn)大量過程式（Procedural）的代碼。所以貧血業(yè)務(wù)對象往往與過程式編程并存。這實際上是違背面向?qū)ο罄砟畹摹Ｓ妹嫦驅(qū)ο蟮恼Z言（Java，C#等）編寫面向過程的軟件，是很多程序員的通病。DDD所以被稱作“OOP done right”,應(yīng)該很大程度上取決于它還原了Service和領(lǐng)域?qū)ο蟮摹罢鎸嵜婺俊薄?/p>

在DDD中，Service處理的是cross-cutting的操作，即不屬于某一個領(lǐng)域?qū)ο?，而屬于某一個Aspect（切面）的操作，有點類似于AOP中的切面。Service可以存在與上面四層中的Application層，或者Domain層，或者Infrastructure層，粒度應(yīng)該不粗也不細。在Adam Bien 的《Real-World Java EE Patterns - Rethinking best practices》一書中，認為Domain-Driven和Service-Oriented是矛盾的: "Domain-driven design and service-oriented design are opposite approaches"。另一方面，因為Service處理的是Cross-cutting的操作，它往往是重構(gòu)的結(jié)果，而不是一開始就建立一堆Service來處理業(yè)務(wù)。業(yè)務(wù)的處理應(yīng)該放在所屬的對象里面，往往是Entity或者VO里。這才是面向?qū)ο?。在處理?fù)雜多變的業(yè)務(wù)需求時這種方式的優(yōu)勢將體現(xiàn)出來。

上面是模型元素Model Components，下面將一起認識生命周期要素Life Cycle Components：聚合Aggregates,工廠Factory，倉儲Repository。

聚合Aggregate是數(shù)據(jù)變化的單位，是一組Entities，VO等組成。聚合有根和邊界。外界訪問聚合只能通過聚合根，只能持有聚合根的引用，不可以持有其他成員的引用。將數(shù)據(jù)變化用聚合來封裝，可以保證數(shù)據(jù)一致性約束、不變量等復(fù)雜的業(yè)務(wù)規(guī)則得到良好的管理。

工廠Factory是用來封裝聚合的創(chuàng)建細節(jié)。注意這里的工廠是概念性的，具體實現(xiàn)可以是工廠方法模式，Builder模式等。一般認為復(fù)雜對象的創(chuàng)建才用工廠。簡單對象直接new就可以。

倉儲Repository封裝對象的存儲和獲取（想起了Spring的XXRepository）。將對象的創(chuàng)建委托給工廠。事務(wù)控制應(yīng)該交給調(diào)用Repository的client。

其他概念如Bounded Context等是與集成有關(guān)的，暫不介紹了。

以上又走馬觀花地review了一遍DDD的重要概念。希望能給讀者一個基本的印象。對DDD來說，也許理解起來很容易（只要對設(shè)計模式、企業(yè)級架構(gòu)有一些經(jīng)驗），但實踐起來很困難，需要不斷摸索。但是早點了解DDD中體現(xiàn)的面向?qū)ο蟮脑O(shè)計思想，對于提高自己的代碼質(zhì)量和架構(gòu)質(zhì)量總是有好處的。

當前標題：初識DDD(DomainDrivenDesign)（二）：軟件架構(gòu)視角
標題鏈接：http://bm7419.com/article32/pcihpc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導(dǎo)航、網(wǎng)站排名、關(guān)鍵詞優(yōu)化、標簽優(yōu)化、微信公眾號、網(wǎng)站導(dǎo)航

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容