實現領域驅動設計

網站

更多書籍點選進入>> CiCi島

下載

電子版僅供預覽及學習交流使用，下載後請24小時內刪除，支援正版，喜歡的請購買正版書籍

• 電子書下載(皮皮雲盤-點選“普通下載”)
• 購買正版

封頁

編輯推薦

著譯俱佳 ThoughtWorks資深諮詢師傾力譯校 　　完整涵蓋DDD各方面知識 提供大量示例程式碼 　　案例貫穿全書 理論與實踐緊密銜接之典範 　　架構師、程式設計師境界提升不可或缺之必選書目

內容簡介

領域驅動設計（DDD）是教我們如何做好軟體的，同時也是教我們如何使用物件導向技術的。它為我們提供了設計軟體的全新視角，同時也給開發者留下了一大難題：如何將領域驅動設計付諸實踐？Vaughn Vernon 的這本《實現領域驅動設計》為我們給出了全面的解答。 　　《實現領域驅動設計》分別從戰略和戰術層面詳盡地討論瞭如何實現DDD，其中包含了大量的實踐、設計準則和對一些問題的折中性討論。《實現領域驅動設計》共分為14 章，在DDD 戰略部分，《實現領域驅動設計》向我們講解了領域、限界上下文、上下文對映圖和架構等內容，戰術部分包括實體、值物件、領域服務、領域事件、聚合和資源庫等內容。一個虛構的案例研究貫穿全書，這對於例項講解DDD 實現來說非常有用。 　　《實現領域驅動設計》在DDD 的思想和實現之間建立起了一座橋樑，架構師和程式設計師均可閱讀，同時也可以作為一本DDD 參考書。

作者簡介

作者：Vaughn Vernon是一個經驗豐富的軟體工匠，在軟體設計、開發和架構方面擁有超過25年的從業經驗。他提倡通過創新來簡化軟體的設計和實現。從20世紀80年代開始，他便開始使用面嚮物件語言進行程式設計；在 20世紀 90年代早期，他便在領域建模中應用了領域驅動設計，那時他使用的是Smalltalk語言。他在很多業務領域都有從業經驗，包括航空、環境、地理、保險、醫學和電信等領域。同時，Vaughn在技術上也取得了很大的成功，包括開發可重用的框架和類庫等。他在全球範圍之內提供軟體諮詢和演講，此外，他還在許多國家教授《實現領域驅動設計》的課程。

目 錄

序 xix

前言 xxi

致謝 xxxi

關於作者 xxxv

如何使用本書xxxvii

第1章 DDD入門

我能DDD嗎？

為什麼我們需要DDD

如何DDD

使用DDD的業務價值

1你獲得了一個非常有用的領域模型

2你的業務得到了更準確的定義和理解

3領域專家可以為軟體設計做出貢獻

4更好的使用者體驗

5清晰的模型邊界

6更好的企業架構

7敏捷、迭代式和持續建模

8使用戰略和戰術新工具

實施DDD所面臨的挑戰

虛構的案例，真實的實踐

本章小結

第2章 領域、子域和限界上下文

總覽

工作中的子域和限界上下文

將關注點放在核心域上

戰略設計為什麼重要

現實世界中領域和子域

理解限界上下文

限界上下文不僅僅只包含模型

限界上下文的大小

與技術元件保持一致

示例上下文

協作上下文

身份與訪問上下文

敏捷專案管理上下文

本章小結

第3章 上下文對映圖

上下文對映圖為什麼重要

繪製上下文對映圖

產品和組織關係

對映3個示例限界上下文

本章小結

第4章 架構

採訪一個成功的CIO

分層

依賴倒置原則

六邊形架構（埠與介面卡）

面向服務架構

REST

REST作為一種架構風格

RESTful HTTP伺服器的關鍵方面

RESTful HTTP客戶端的關鍵方面

REST和DDD

為什麼是REST？

命令和查詢職責分離——CQRS

CQRS的各個方面

處理具有最終一致性的查詢模型

事件驅動架構

管道和過濾器

長時處理過程（也叫Saga）

事件源

資料網織和基於網格的分散式計算

資料複製

事件驅動網織和領域事件

持續查詢

分散式處理

本章小結

第5章 實體

為什麼使用實體

唯一標識

使用者提供唯一標識

應用程式生成唯一標識

持久化機制生成唯一標識

另一個限界上下文提供唯一標識

標識生成時間

委派標識

標識穩定性

發現實體及其本質特徵

揭開實體及其本質特徵的神祕面紗

挖掘實體的關鍵行為

角色和職責

建立實體

驗證

跟蹤變化

本章小結

第6章 值物件

值物件的特徵

度量或描述

不變性

概念整體

可替換性

值物件相等性

無副作用行為

最小化整合

用值物件表示標準型別

測試值物件

實現

持久化值物件

拒絕由資料建模洩漏帶來的不利影響

ORM與單個值物件

多個值物件序列化到單個列中

使用資料庫實體儲存多個值物件

使用聯合表儲存多個值物件

ORM與列舉狀態物件

本章小結

第7章 領域服務

什麼是領域服務（首先，什麼不是領域服務）

請確定你是否需要一個領域服務

建模領域服務

獨立介面有必要嗎

一個計算過程

轉換服務

為領域服務建立一個迷你層

測試領域服務

本章小結

第8章 領域事件

何時/為什麼使用領域事件

建模領域事件

建立具有聚合特徵的領域事件

身份標識

從領域模型中釋出領域事件

傳送方

訂閱方

向遠端限界上下文釋出領域事件

訊息設施的一致性

自治服務和系統

容許時延

事件儲存

轉發儲存事件的架構風格

以REST資源的方式釋出事件通知

通過訊息中介軟體釋出事件通知

實現

釋出NotificationLog

釋出基於訊息的事件通知

本章小結

第9章 模組

通過模組完成設計

模組的基本命名規範

領域模型的命名規範

敏捷專案管理上下文中的模組

其他層中的模組

先考慮模組，再是限界上下文

本章小結

第10章 聚合

在Scrum核心領域中使用聚合

第一次嘗試：臃腫的聚合

第二次嘗試：多個聚合

原則：在一致性邊界之內建模真正的不變條件

原則：設計小聚合

不要相信每一個用例

原則：通過唯一標識引用其他聚合

通過標識引用使多個聚合協同工作

建模物件導航性

可伸縮性和分散式

原則：在邊界之外使用最終一致性

誰的任務？

打破原則的理由

理由之一：方便使用者介面

理由之二：缺乏技術機制

理由之三：全域性事務

理由之四：查詢效能

遵循原則

通過發現，深入理解

重新思考設計

估算聚合成本

常見用例場景

記憶體消耗

探索另外的設計

實現最終一致性

這是Scrum團隊成員的任務嗎？

決定的時候到了

實現

建立具有唯一標識的根實體

優先使用值物件

使用迪米特法則和“告訴而非詢問”原則

樂觀併發

避免依賴注入

本章小結

第11章 工廠

領域模型中的工廠

聚合根中的工廠方法

建立CalendarEntry例項

建立Discussion例項

領域服務中的工廠

本章小結

第12章 資源庫

面向集合資源庫

Hibernate實現

TopLink實現

面向持久化資源庫

Coherence實現

MongoDB實現

額外的行為

管理事務

警告

型別層級

資源庫 vs 資料訪問物件（DAO）

測試資源庫

以記憶體實現進行測試

本章小結

第13章 整合限界上下文

整合基礎知識

分散式系統之間存在根本性區別

跨系統邊界交換資訊

通過REST資源整合限界上下文

實現REST資源

使用防腐層實現REST客戶端

通過訊息整合限界上下文

從Scrum的產品負責人和團隊成員處得到持續通知

你能處理這樣的職責嗎？

長時處理過程，以及避免職責

長時處理過程的狀態機和超時跟蹤器

設計一個更復雜的長時處理過程

當訊息機制或你的系統不可用時

本章小結

第14章 應用程式

使用者介面

渲染領域物件

渲染資料傳輸物件

使用調停者釋出聚合的內部狀態

通過領域負載物件渲染聚合例項

聚合例項的狀態展現

用例優化資源庫查詢

處理不同型別的客戶端

渲染介面卡以及處理使用者編輯

應用服務

示例應用服務

解耦服務輸出

組合多個限界上下文

基礎設施

企業元件容器

本章小結

附錄A 聚合與事件源：A ES

應用服務內部

命令處理器

Lambda語法

併發控制

A ES所帶來的結構自由性

效能

實現事件儲存

關係型持久化

BLOB持久化

專注的聚合

讀模型投射

與聚合設計一道使用

增強事件

工具和模式

事件序列器

事件不變性

值物件

協議生成

單元測試和需求規範

事件源和函式式語言

參考文獻

前 言

　　所有的計算都表明它不工作，唯一的做法是：使其工作。 --Pierre-Georges Latécoère早期法國航空企業家
　　是的，我們將使其工作。然而，在軟體開發過程中採用領域驅動設計卻是困難的。即便是有能力的開發者，也很難找到實現領域驅動設計的正確方法。
　　起飛，著陸
　　在我小的時候，我的父親學習過駕駛小型飛機。我們經常會全家出去飛行，有時會飛到另一個機場，在那裡吃過午飯後再返回。當父親時間有限而他依然想飛時，父親便帶上我一起在機場上空盤旋，起飛，著陸，再起飛，再著陸。
　　也會有些長途飛行，這時我們會帶上一張由父親先前繪製好的路線圖。我們幾個小孩便當起了領航員：將圖上的標誌對應著陸地上的地標，以確保我們沒有跑偏航線。這是一件很有趣的事情，因為要識別遠在地面上的物體是很有挑戰性的。事實上，我敢肯定父親根本不用我們領航便知道我們處於什麼方位--他能看到儀表盤上的所有資訊，並且他擁有儀表飛行執照。
　　空中的景觀的確改變了我的視野。不時地，父親和我會飛過我們鄉下的房子。在幾百英尺的高空中，我體會到了另一種“家”的概念，而這在之前是沒有過的。當我們飛過自家的房子時，母親和我的姐妹們便會跑到院子裡向我們揮手。我知道那是她們，即便我看不清楚她們是誰。談話肯定是不行的，連大聲喊都不行，她們是聽不見的。我還可以看到將我家和外面公路分開的護欄，平時我們會像走平衡木一樣在護欄上面走來走去。從空中看，它們就像被細心編排過的小樹枝一樣。我們
　　家的院子很大，每每到了夏天，我都會開著割草機一排一排地修理院子裡的草坪。而在空中時，我只能看到一片綠色，小草的葉子肯定是看不清楚的。
　　我喜歡在空中的時刻，直到現在我還不時回想起這些時刻，好像那個降落飛
　　機的黃昏就發生在不久以前一樣。雖然如此，在地面上的感覺依然是無法取代的，
　　因為它給我一種腳踏實地的感覺。
　　著陸於領域驅動設計
　　一開始接觸領域驅動設計（ DDD）就像一個小孩之於飛行一樣。天空中的景色是令人驚歎的，但有時我們卻因為過於陌生而搞不明白它們到底是什麼。要從甲地到乙地顯得如此的遙遠。然而， DDD的“成年人 “們卻總知道他們所處的方位，因為他們在很早之前便繪製好了路線圖，並且能夠完全按照儀表進行相應的操作。而還有很多人找不到”在地面上“的感覺，此時我們需要的是”穩定著陸“的能力，然後找到一張地圖給我們指引方向。
　　Eric Evans的《領域驅動設計：軟體核心複雜性應對之道》是一本經得住時間考驗的經典之作。我堅定地相信，在接下來的幾十年裡，本書依然會是開發者的實用指導。和其他模式一樣，該書為我們建立起了一種高屋建瓴式的寬闊視野。然而，對於如何實現 DDD，我們可能將面對更多的挑戰。通常來說，我們更渴望看到一些具體的例子。
　　我的目標之一便是幫助你來一個”軟著陸“，保全飛機，然後沿著一條周知的線路帶你回家。這將幫助你如何更好地去實現 DDD，並且通過你所熟悉的工具和技術給出示例演示。當然，任何一個人都不可能一直呆在家裡，所以我還會帶領你到新的地帶去冒險，這些地帶你可能從來沒有去過。冒險之路是險峻的，但是在正確的戰術應對下，征服這些困難是可能的。在這條冒險之路上，你將學到另外的架構和模式來整合多個領域模型。你將接觸到先前沒有被研究過的整合方法，並且學到如何開發自治性服務。
　　我將向你提供一張對短途旅行和長途旅行均適用的地圖，它可以幫助你更好地享受沿途風景，同時又不至於迷失途中。
　　對照地形，繪製飛行圖
　　在軟體開發的過程中，我們經常做的一件事便是將一種東西對映到另一種東西。我們將物件對映到資料庫，對映到使用者介面，或者對映到不同的應用層展現（包括作為消費方的其他系統或應用程式）。在所有這些對映中，我們很自然地希望在Evans提出的高層模式和具體實現之間存在一種對映。
　　即便你已經接觸過 DDD，你依然有很多可以獲益的地方。有時， DDD首先被看作是一套技術工具集，有人將此稱為 DDD-Lite。我們可能已經對實體、服務等 DDD概念非常熟悉了，並且大膽地嘗試著設計聚合，還通過資源庫來管理持久化。這些模式是大家相對熟知的，使用起來很容易，我們甚至還使用了值物件。以上這些都屬於戰術設計模式範疇，也即更加偏向技術層面。這些模式可以很好地幫我們解決軟體問題。而同時，對於戰術性模式，我們依然有許多需要學習的。我將戰術模式對映到實現層面。
　　你曾瞭解過戰術建模之外的東西嗎？你曾瞭解過被稱為 DDD”另一半“的戰略設計模式嗎？如果你還沒有使用過限界上下文和上下文對映圖，那麼你很有可能也沒有使用過通用語言。
　　如果說 Evans在軟體開發社群有一項發明，那便是通用語言。通用語言是一種團隊協作模式，用於捕捉特定業務領域中的概念和術語。一個特定領域的軟體模型通過不同的名詞、形容詞和動詞來表達，這些詞彙是開發團隊正式使用的，而團隊中應該包含一個或多個領域專家。然而，將通用語言僅限定於一些詞彙則是錯誤的。就像自然語言反映人們的思想一樣， DDD的通用語言反映了領域專家對於軟體系統的思維模型。通用語言和那些戰略和戰術性的建模模式同等重要，在有些情況下甚至更具有永續性。
　　簡單地講， DDD-Lite將導致劣質的領域物件，因為通用語言、限界上下文和上下文對映圖的作用太大了，你從其中獲得的並不只是一套團隊共用的語言。在限界上下文中用通用語言來表述一個領域模型可以增加業務價值，並且使我們確信所開發軟體的正確性。即使從技術的角度，它也可以幫助我們建立更好的領域模型，這樣的模型行為豐滿，業務純淨，並且可以減少犯錯誤的可能性。因此，我將戰略設計模式對映到了可理解的實際例子中。
　　本書對於 DDD的對映可以幫助你同時體會到戰略設計和戰術設計的好處。通過一些具體的例子，你將感受到這些 DDD對映的業務價值和技術展現力。
　　如果我們對於 DDD的所有實踐都只是停留在”地面上“，那將是令人失望的。過度地拘泥於細節將使我們喪失在空中俯瞰的機會。所以，不要將自己侷限在地面的細節上，要勇敢地飛翔在空中，居高臨下。搭上戰略設計的航班，去了解限界上下文和上下文對映圖，你將獲得更廣闊的視野。當你從 DDD的航班中獲益時，我的目的也就達到了。
　　各章概要
　　以下是各章的主要內容以及你將如何從中獲益。
　　第1章：DDD入門
　　本章向你介紹 DDD的好處，並且教你如何儘可能多地去實現 DDD。你將學到當你在應對複雜的軟體系統時， DDD可以為你的專案和團隊帶來什麼。同時，你將瞭解到通常的 DDD替代方案以及這些方案為什麼會導致問題。作為對 DDD的基礎講解，本章將教你如何在專案中開始採用 DDD，還有如何向你的領域專家和技術團隊推銷 DDD。在DDD的武裝下，你將學會如何迎接挑戰，勇往直前。
　　本章將介紹關於一個公司及其團隊的案例研究，雖然該公司是虛構的，但是他們所面臨的 DDD挑戰卻是真實存在的。該公司旨在開發一個新的多租戶 SaaS（Software as a Service，軟體即服務）軟體產品。不出所料，在使用 DDD時，他們犯了一些常見的錯誤。不過還好，他們發現了這些錯誤，並解決了一些問題，因此專案還算沒有偏離正軌。該團隊需要開發一套基於 Scrum的專案管理軟體。該案例還會在本書的後續章節中連續講到。每一種戰略和戰術模式都將教給這個團隊。在這個過程中，團隊有誤入歧途的時候，但最終他們將向著成功的 DDD實踐昂首闊步。
　　第2章：領域、子域和限界上下文
　　領域、子域和核心域分別是什麼？限界上下文是什麼，我們為什麼要使用它，並且如何使用？這些問題將在這個 SaaS專案團隊犯錯誤的時候給予解答。在他們的第一個 DDD專案中，他們並不瞭解子域、限界上下文和通用語言這些概念。事實上，他們根本不知道什麼是戰略設計，只是採用了戰術設計來解決一些技術問題。這樣他們在開始設計領域模型的時候便遇到了不少問題。幸運的是，他們及時地意識到了這些問題，專案還有挽回的餘地。
　　本章還講到了如何使用限界上下文對模型進行分離，這是非常重要的；同時還講到了一些模型分離不當的反例，並且給出了有效的實現建議。在採用了這些建議之後，該團隊的成員們重新建立了兩個不同的限界上下文。這種合理的模型分離帶來的好處是引出了第三個限界上下文--核心域，這將是本書使用的主要例子。
　　對於那些苦於單單從技術層面應用 DDD的人來說，本章應該能引起你的共鳴。如果你還是 DDD戰略設計的外行，那麼本章將為你指明方向。
　　第 3章：上下文對映圖
　　上下文對映圖幫助我們理解業務領域、模型間的邊界，以及這些模型之間的整合方式。
　　上下文對映圖絕對不只是繪製系統架構圖這麼簡單，它處理的是不同限界上下文之間的關係，以及如何在不同的模型之間對映物件。對於在複雜的業務系統中使用好限界上下文，這是至關重要的。在第 2章中，團隊成員們在首次嘗試限界上下文時碰到了問題。本章中，他們將學著如何利用上下文對映圖來解決這些問題。這樣的結果是產生了兩個體面的限界上下文，這兩個上下文將被另外一個負責核心域的團隊所使用。
　　第 4章：架構
　　我們都知道分層架構，但它是開發 DDD軟體的唯一方式嗎，也或許還存在另外的方式？在本章中，我們將講到：六邊形架構（埠和介面卡）、面向服務架構、REST、CQRS、事件驅動（管道和過濾器，長時處理過程，事件源）和資料網格，其中好幾種架構都將被該團隊成員所採用。
　　第 5章：實體
　　在DDD的戰術模式中，我們將首先講到實體。團隊成員們一開始過於強調實體的作用而忽視了值物件。受到資料庫和持久化框架的影響，實體被該團隊濫用了，此時他們開始討論如何避免大範圍地使用實體。
　　在本章中，你將看到很多優秀的實體設計例子。同時，本章還將講到如何使用實體來表達通用語言，以及如何對實體進行測試、實現和持久化。
　　第 6章：值物件
　　早些時候，團隊成員們錯過了採用值物件的好機會。他們過於注重為實體建立一些單一的屬性，這種方式是欠妥的，更好的方式是將這些單一的屬性聚合成一個不變的整體。本章將從不同的角度講解如何設計值物件，以及在什麼時候採用值物件會優於實體。同時，本章還包含了一些其他話題，比如值物件在整合中的角色和對標準型別的建模等。然後，本章講到了如何設計以領域為中心的測試，如何實現值物件。此外，本章還講到了在聚合中儲存值物件時，如何避免持久化機制所帶來的不利影響。
　　第 7章：領域服務
　　本章將講到，在領域模型中，什麼時候應該將一個概念建模成粒度適中，並且無狀態的領域服務。你將學到何時應該使用領域服務而不是實體或值物件，以及如何使用領域服務來處理業務邏輯和技術上的整合。團隊成員們向我們展示了何時應該使用領域服務，以及如何設計領域服務。
　　第 8章：領域事件
　　Eric Evans並沒有在他的書中正式介紹領域事件，領域事件是在他那本書出版之後才進入人們視野的。在本章中，你將學到為什麼領域事件如此有用，以及使用領域事件的不同方法。領域事件甚至被用來輔助整合和自治性服務。在軟體系統中，我們經常使用一些技術層面的事件機制，但本章將著重講解領域事件與這些事件機制的區別。本章還將指導你如何設計並實現領域事件，包括一些可行的方案和對這些方案的權衡選擇。然後，本章將講到如何建立一個釋出 -訂閱機制；如何利用事件來整合整個企業軟體中的各個訂閱方；如何建立和管理事件儲存；如何處理訊息機制所面臨的常見挑戰等。
　　第 9章：模組
　　對於模型中的物件，我們應該如何將他們組織在大小適中的容器中呢？我們又如何保證不同容器中的物件之間只存在有限的耦合？另外，我們如何對這些容器進行命名以體現通用語言？除了包和名稱空間之外，我們如何使用由語言和框架提供的現代模組化機制，比如 OSGi和Jigsaw？在本章中，你將看到 SaaS團隊成員是如何在不同的專案中使用模組的。
　　第 10章：聚合
　　在DDD的戰術模式中，聚合可能是最不容易理解的了。然而，在遵循一定的經驗法則的情況下，我們是能夠更簡單、更快地實現聚合的。在本章中你將學到：如何利用聚合在不同的小規模物件叢集間建立一致性邊界，從而降低模型的複雜性。由於在細枝末節上花了太多精力， SaaS團隊成員們在設計聚合時總是磕磕絆絆。我們將仔細研究該團隊所面臨的挑戰，並且分析錯誤的原因以及他們的應對策略。結果，團隊成員們對他們的核心域有了更深層次的理解。我們將看到，在合理的事務處理和保證最終一致性（Eventual Consistency）的前提下，該團隊更正了他們所犯的錯誤，並且在一個分散式環境中設計出了更具有伸縮性和更高效的模型。
　　第 11章：工廠
　　工廠已經在 [Gamma et al.]中被大量地談及了，為什麼還要講呢？本章並不打算重蹈覆轍，而是將重點放在”工廠應該存在於何處“這個問題上。在本章中，我們將講到在 DDD中實現工廠的技巧。團隊成員在他們的核心域中建立的工廠可以簡化客戶端介面，並且對模型的消費方起到保護作用，從而避免了在多租戶環境中引入災難性的 bug。
　　第 12章：資源庫
　　資源庫只是一個資料訪問物件（ Data Access Object， DAO）嗎？如果不是，它們之間有什麼區別呢？我們為什麼應該將資源庫看成是對集合的模擬而非資料庫呢？在本章中，我們將講到如何利用 ORM來實現資源庫，其中有兩種 ORM方案，一種採用基於網格的分散式快取，另一種則採用 NoSQL的鍵值對儲存。團隊成員們可以採用任何一種作為他們的持久化機制。
　　第 13章：整合限界上下文
　　到現在為止，你已經瞭解了戰略層次的上下文對映圖和多種戰術層次的模式。本章將講到，在 DDD中，我們如何通過上下文對映圖來整合不同的模型。在團隊對核心域和其他輔助性的限界上下文進行整合時，我們將給出相應的建議和指導。
　　第14章：應用程式
　　對於每一個核心域的通用語言，我們都設計了相應的模型，並且進行了足夠的測試，模型工作正常。然而，客戶應該如何使用我們的模型呢？他們應該使用 DTO將資料在模型和使用者介面之間傳輸嗎？或者存在其他方案可以實現模型和展現元件間的資料傳遞？ DDD中的應用服務和基礎設施是如何工作的？對於這些問題，本章都將做出解答。
　　附錄A：聚合與事件源： A ES
　　事件源是一種持久化聚合的重要技術，同時也是事件驅動架構的基礎。事件源通過一系列的事件來表示聚合的所有狀態。通過有序的事件重放，我們可以重新構建聚合的狀態。當然，使用事件源的前提是：它能夠簡化對資料的持久化，並且能夠捕捉到那些具有複雜行為屬性的概念。
　　Java和開發工具
　　本書中的絕大多數例子都是使用 Java語言編寫的。我本來可以用 C#的，但是我有意識地使用了 Java。
　　首先，我認為 Java社群正在拋棄好的軟體設計和開發實踐。現在，對於多數 Java專案而言，要在其中找到一個好的領域物件恐怕是困難的。在我看來， Scrum和敏捷被人們看成了優良設計的替代品，而其中的產品待定項（Product Backlog）被看成了設計本身。多數敏捷人士並不會過多地去思考這些待定項是否會影響到業務模型。我得說明， Scrum的本意絕對不是要取代設計。不管有多少專案經理想將你捆綁在持續交付這條路上，我得說 Scrum並不僅僅是要取悅於那些甘特圖（ Gantt chart）的追隨者們。然而，太多的時候，情況的確是這樣的。
　　我認為這是個很大的問題，所以我想鼓勵 Java社群重新回到領域建模中來，同時我會通過本書向大家說明，設計是可以使我們獲益的。
　　此外，在 .NET社群中已經有很好的DDD資源了，比如Jimmy Nilsson的《領域驅動設計與模式實戰》[Nilsson]。由於Jimmy的出色工作和其他人對Alt.NET的倡導，.NET社群中正掀起一陣優秀設計的開發浪潮，這是Java社群需要注意的。
　　其次，我意識到 C#.NET人員在理解 Java程式碼上並不存在什麼困難。由於很多 DDD社群的人都在使用 C#.NET，而本書的早期校對人員也都是 C#程式設計師，但是我從來就沒有收到他們的抱怨。因此，我便不用顧慮這些了。
　　在我寫這本書時，業內正將目光從關係型資料庫轉向基於文件和鍵值對的儲存方案。這是有原因的， Martin Fowler將這些儲存方案稱為”面向聚合儲存“。這種命名是恰當的，它很好地描述了在 DDD中使用 NoSQL的好處。
　　但是，就我從事諮詢的經驗來看，很多開發者還是認定了關係型資料庫和物件-關係對映。因此我想， NoSQL追隨者們應該能夠理解我在書中包含物件 -關係對映的章節。然而，我的確得承認，這可能會招致那些認為存在物件 -關係阻抗失配（Object-Relational Impedance）的人的鄙視。這無所謂，對此我表示接受，因為絕大多數人在他們的日常工作中都還得面對這種物件 -關係阻抗失配。
　　當然，在第 12章”資源庫“中，我同樣提供了基於文件的、鍵值對的和資料網格的儲存方案。在多處地方，我都討論到了 NoSQL對聚合設計的影響。 NoSQL趨勢很有可能持續下去，那些物件 -關係型的開發者們應該注意了。在本書中你將看到，我能夠同時理解兩個陣營的觀點，並且對於雙方的觀點我都同意。這些都是技術趨勢所導致的摩擦，而這對於積極的變革是有必要的。

媒體評論

     ★“在《實現領域驅動設計》中，Vaughn不僅為DDD領域做出了貢獻，還為更寬闊的企業應用架構領域寫上了厚重的一筆。例如，在架構和資源庫等核心章節中，Vaughn向我們展示瞭如何將DDD與各種架構風格和持久化技術融合在一起——包括SOA、REST、NoSQL和資料網格等——其中很多都是在Eric Evans那本DDD開山之作出版之後才出現的。另外，書中還講到了對實體、值物件、聚合、領域服務、事件、工廠和資源庫的實現，其中包括大量的例子。一言以蔽之，我認為這本書非常全面。對於那些希望提升自己技能的軟體開發者來說，《實現領域驅動設計》將是一本的好書。”

　　——Randy Stafford，自由架構師，Oracle Coherence產品部
　　
　　★“領域驅動設計是一套非常強大的思想工具，它深遠地影響著軟體開發團隊的效率。問題在於，許多開發者在應用這套思想工具時會不時地迷失方向，他們需要更實際的指導建議。在本書中，Vaughn將理論與實踐聯絡在了一起。除了為我們講解那些易被誤解的DDD概念之外，Vaughn還講到了一些新的概念，比如命令/查詢職責分離（CQRS）和事件源等。對於那些希望實際應用DDD的人來說，這是一本必讀之作。”
　　——Udi Dahan，NServiceBus創始人
　　
　　★“多年以來， DDD的開發者們都希望獲得一些更實際的幫助。 Vaughn縫合了理論和實踐之間的間隙，向大家提供了一套完整的 DDD實現參考。他向我們展示瞭如何在當前軟體專案中使用DDD，並且向我們提出了大量的實際建議。 “
　　——Alberto Brandolini，DDD導師（由 Eric Evans和Domain Language， Inc頒發證照）
　　
　　★“《實現領域驅動設計》清晰地向我們展示了 DDD的核心話題。本書的寫作風格非常友好，就像一個值得信賴的導師在給你講課一樣。讀完本書，你將能夠應用 DDD的各個重要概念。我在閱讀本書的時候，在很多章節中都做上了著重標記……我會經常地參考並推薦本書。”
　　——Paul Rayner，首席諮詢師， DDD導師（由 Eric Evans和Domain Language， Inc頒發證照）， DDD Denver創始人。
　　
　　★“在我所教的 DDD課程中，很重要的一點便是如何將所有的 DDD理論付諸實踐。有了本書， DDD社群便有了可供參考的資料。《實現領域驅動設計》包含了建立 DDD系統的方方面面，從具體的實現細節到高層的設計思想。這是一本了不起的 DDD參考書，同時也是 Eric Evans那本 DDD開山之作的伴侶。 “
　　——Patrik Fredriksson，DDD導師（由 Eric Evans和Domain Language， Inc頒發證照）
　　
　　★“如果你關心軟體工藝——你也應該這麼做——那麼領域驅動設計便是非常重要的一項技能，而《實現領域驅動設計》則向我們提供了一條邁向成功的捷徑。本書詳盡地討論了 DDD的戰略模式和戰術模式，使開發者能夠立即將理論付諸實踐。今後的業務軟體系統將從本書中受益匪淺。”
　　——Dave Muirhead，首席諮詢師， Blue River Systems 集團
　　
　　★“DDD既有理論，也有實踐，這些都是每個開發者應該瞭解的，而本書則很好地彌補了理論與實踐之間的差距。強烈推薦本書！ “
　　——Rickard Oberg，Java開發者， Neo Technology公司
　　
　　★“在《實現領域驅動設計》中， Vaughn採用了自頂向下的方法，首先講到了 DDD的戰略模式，比如限界上下文和上下文對映圖，然後講到了戰術模式，比如實體、值物件和領域服務等。案例研究貫穿全書，要從中有所學，你需要在該案例研究上下足功夫。如果你這麼做了，你便能看到將 DDD應用於複雜領域的意義所在。書中包含了大量的旁註、圖示和示例程式碼。如果你希望使用當下常見的架構風格來建立一個 DDD系統，那麼 Vaughn的這本《實現領域驅動設計》便是我所推薦的。”
　　——Dan Haywood，《Domain-Driven Design with Naked Objects》作者
　　
　　★“本書採用了一種自頂向下的方式來講解 DDD，這種方式將 DDD的戰略模式和戰術模式自然地銜接起來。在本書中， Vaughn強調了業務領域的價值，同時也給出了技術上的討論。因此， DDD在軟體開發中的角色也變得非常清晰。很多時候，我的團隊，包括我本人，在應用 DDD時都會遇到這樣那樣的麻煩。有了《實現領域驅動設計》的指導，我們得以克服種種挑戰，進而將付出立即轉化為業務價值。 “
　　——Lev Gorodinski，首席架構師， DrillSpot.com