初識DDD(Domain Driven Design) （二）：軟件架構視角

   本文將從軟件架構角度，介紹DDD的分層架構、組成要素、領域對象生命周期管理等核心概念。

   DDD（Domain Driven Design，領域驅動設計）核心是針對業務層建模的，但是為了保證業務層的相對獨立性，DDD從最佳實踐經驗出發提出了下面的系統分層：

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

   各層的基本職責如下：    

1. UI層：與常用的Presentation Tier類似，負責與客戶端交互、展示界面等。上圖也表示了UI層可以調用下面的任一層。

2. Application層：相當于一個Facade，是薄的一層。定義軟件要做的任務，協調和組織（coordinate）完成用戶請求需要的作業(tasks)并委托(delegate)給Domain層的調用。沒有業務邏輯（rules, knowledge）在里面。功能有點類似于企業級模式和J2EE模式Front Controller。

3. Domain層：業務軟件的核心。負責表示業務概念，業務狀況和業務規則。需要注意的是對業務狀態的保存（持久化）的技術細節不屬于這一層（不屬于業務模型），而要委托給Infrastructure層。在該層內部，應該采用Model Driven Design。

4. Infrastructure層：顧名思義，該層負責提供上面各層需要的通用性服務，如發送消息（Messaging）,領域對象的持久化，提供繪制UI所需的Widget，提供各層通信所需框架等。

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

   我們從基礎的四個元素或說概念說起：Entity，Value Object, Module, Association。Entity用來表示有Identity（俗稱ID）的領域對象。Value Object用來表示沒有Identity的領域值對象。這些對象都帶有屬于領域對象的行為。Association表示他們之間的聯系。Module也可以叫Package，用來封裝概念上內聚的一組DDD元素，表達一個具體的領域概念，相當于Java中的package。

   需要注意的是DDD中的Entity與常見的基于SSH框架所做的系統中的Entity的區別。后者往往稱為貧血的業務對象（amemic domain object），因為它們只與持久化相關而沒有所屬的業務行為，只有getter/setter之類的基本方法。相應地那些業務行為移到了"Service"中。于是Service（或者ServiceImpl）中出現大量過程式（Procedural）的代碼。所以貧血業務對象往往與過程式編程并存。這實際上是違背面向對象理念的。用面向對象的語言（Java，C#等）編寫面向過程的軟件，是很多程序員的通病。DDD所以被稱作“OOP done right”,應該很大程度上取決于它還原了Service和領域對象的“真實面目”。

   在DDD中，Service處理的是cross-cutting的操作，即不屬于某一個領域對象，而屬于某一個Aspect（切面）的操作，有點類似于AOP中的切面。Service可以存在與上面四層中的Application層，或者Domain層，或者Infrastructure層，粒度應該不粗也不細。在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的操作，它往往是重構的結果，而不是一開始就建立一堆Service來處理業務。業務的處理應該放在所屬的對象里面，往往是Entity或者VO里。這才是面向對象。在處理復雜多變的業務需求時這種方式的優勢將體現出來。

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

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

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

   倉儲Repository封裝對象的存儲和獲取（想起了Spring的XXRepository）。將對象的創建委托給工廠。事務控制應該交給調用Repository的client。

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

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