編輯推薦

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

內容簡介

　　領域驅動設計（DDD）是教我們如何做好軟件的，同時也是教我們如何使用麵嚮對象技術的。它為我們提供瞭設計軟件的全新視角，同時也給開發者留下瞭一大難題：如何將領域驅動設計付諸實踐？Vaughn Vernon 的這本《實現領域驅動設計》為我們給齣瞭全麵的解答。

　　《實現領域驅動設計》分彆從戰略和戰術層麵詳盡地討論瞭如何實現DDD，其中包含瞭大量的實踐、設計準則和對一些問題的摺中性討論。《實現領域驅動設計》共分為14 章，在DDD 戰略部分，《實現領域驅動設計》嚮我們講解瞭領域、限界上下文、上下文映射圖和架構等內容，戰術部分包括實體、值對象、領域服務、領域事件、聚閤和資源庫等內容。一個虛構的案例研究貫穿全書，這對於實例講解DDD 實現來說非常有用。

　　《實現領域驅動設計》在DDD 的思想和實現之間建立起瞭一座橋梁，架構師和程序員均可閱讀，同時也可以作為一本DDD 參考書。

作者簡介

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

精彩書評

　　★“在《實現領域驅動設計》中，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

目錄

序
前言
緻謝
關於作者
如何使用本書
第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持久化
專注的聚閤
讀模型投射
與聚閤設計一道使用
增強事件
工具和模式
事件序列器
事件不變性
值對象
協議生成
單元測試和需求規範
事件源和函數式語言
參考文獻

精彩書摘

　　當然，對於“當……的時候，請通知我”，這裏的通知本身並不能構成一個事件，而隻是錶明我們需要嚮外界發齣通知。另外，領域專傢可能還會說“如果發生這樣的事情，它並不重要；如果發生那樣的事情，它就很重要瞭（將“這樣”和“那樣”用你自己領域中的事件予以替換）。”根據你的組織文化，可能還有更多的事件用語。
　　牛仔的邏輯
　　有時，從領域專傢的話中，我們看不齣領域事件的跡象，但是業務需求依然有可能需要領域事件。領域專傢有可能意識不到這些需求，隻有在跨團隊討論之後他們纔能意識到這些。發生這樣的事情往往是由於領域事件需要發布到外部係統中，比如發布到另一個限界上下文中（2）。由於這樣的事件由訂閱方處理，它將對本地和遠程上下文産生深遠的影響。
　　領域專傢和領域事件
　　雖然領域專傢在起初可能意識不到所有類型的領域事件，但是通過討論之後，他們是應該能夠瞭解到其中的原因的。當團隊成員對領域事件達成一緻之後，領域事件便是通用語言的正式組成部分瞭。
　　當領域事件到達目的地之後一一無論是本地係統還是外部係統一一我們通常都將領域事件用於維護事件的一緻性。這是有意而為之的，並且是根據設計而來的。這樣可以消除兩階段提交（全局事務），還可以支持聚閤（10）原則。聚閤的其中一個原則是，在單個事務中，隻允許對一個聚閤實例進行修改，由此産生的其他改蠻必須存單獨的事務中完成。

　　……

前言/序言

　　所有的計算都錶明它不工作，唯一的做法是：使其工作。 --Pierre-Georges Latécoère早期法國航空企業傢
　　是的，我們將使其工作。然而，在軟件開發過程中采用領域驅動設計卻是睏難的。即便是有能力的開發者，也很難找到實現領域驅動設計的正確方法。
　　起飛，著陸
　　在我小的時候，我的父親學習過駕駛小型飛機。我們經常會全傢齣去飛行，有時會飛到另一個機場，在那裏吃過午飯後再返迴。當父親時間有限而他依然想飛時，父親便帶上我一起在機場上空盤鏇，起飛，著陸，再起飛，再著陸。
　　也會有些長途飛行，這時我們會帶上一張由父親先前繪製好的路綫圖。我們幾個小孩便當起瞭領航員：將圖上的標誌對應著陸地上的地標，以確保我們沒有跑偏航綫。這是一件很有趣的事情，因為要識彆遠在地麵上的物體是很有挑戰性的。事實上，我敢肯定父親根本不用我們領航便知道我們處於什麼方位--他能看到儀錶盤上的所有信息，並且他擁有儀錶飛行執照。
　　空中的景觀的確改變瞭我的視野。不時地，父親和我會飛過我們鄉下的房子。在幾百英尺的高空中，我體會到瞭另一種“傢”的概念，而這在之前是沒有過的。當我們飛過自傢的房子時，母親和我的姐妹們便會跑到院子裏嚮我們揮手。我知道那是她們，即便我看不清楚她們是誰。談話肯定是不行的，連大聲喊都不行，她們是聽不見的。我還可以看到將我傢和外麵公路分開的護欄，平時我們會像走平衡木一樣在護欄上麵走來走去。從空中看，它們就像被細心編排過的小樹枝一樣。我們
　　傢的院子很大，每每到瞭夏天，我都會開著割草機一排一排地修理院子裏的草坪。而在空中時，我隻能看到一片綠色，小草的葉子肯定是看不清楚的。
　　我喜歡在空中的時刻，直到現在我還不時迴想起這些時刻，好像那個降落飛
　　機的黃昏就發生在不久以前一樣。雖然如此，在地麵上的感覺依然是無法取代的，
　　因為它給我一種腳踏實地的感覺。
　　著陸於領域驅動設計
　　一開始接觸領域驅動設計（ DDD）就像一個小孩之於飛行一樣。天空中的景色是令人驚嘆的，但有時我們卻因為過於陌生而搞不明白它們到底是什麼。要從甲地到乙地顯得如此的遙遠。然而， DDD的“成年人 “們卻總知道他們所處的方位，因為他們在很早之前便繪製好瞭路綫圖，並且能夠完全按照儀錶進行相應的操作。而還有很多人找不到”在地麵上“的感覺，此時我們需要的是”穩定著陸“的能力，然後找到一張地圖給我們指引方嚮。
　　Eric Evans的《領域驅動設計：軟件核心復雜性應對之道》是一本經得住時間考驗的經典之作。我堅定地相信，在接下來的幾十年裏，本書依然會是開發者的實用指導。和其他模式一樣，該書為我們建立起瞭一種高屋建瓴式的寬闊視野。然而，對於如何實現 DDD，我們可能將麵對更多的挑戰。通常來說，我們更渴望看到一些具體的例子。
　　我的目標之一便是幫助你來一個”軟著陸“，保全飛機，然後沿著一條周知的綫路帶你迴傢。這將幫助你如何更好地去實現 DDD，並且通過你所熟悉的工具和技術給齣示例演示。當然，任何一個人都不可能一直呆在傢裏，所以我還會帶領你到新的地帶去冒險，這些地帶你可能從來沒有去過。冒險之路是險峻的，但是在正確的戰術應對下，徵服這些睏難是可能的。在這條冒險之路上，你將學到另外的架構和模式來集成多個領域模型。你將接觸到先前沒有被研究過的集成方法，並且學到如何開發自治性服務。
　　我將嚮你提供一張對短途旅行和長途旅行均適用的地圖，它可以幫助你更好地享受沿途風景，同時又不至於迷失途中。
　　對照地形，繪製飛行圖
　　在軟件開發的過程中，我們經常做的一件事便是將一種東西映射到另一種東西。我們將對象映射到數據庫，映射到用戶界麵，或者映射到不同的應用層展現（包括作為消費方的其他係統或應用程序）。在所有這些映射中，我們很自 實現領域驅動設計 [Implementing Domain-Driven Design] 下載 mobi epub pdf txt 電子書

在20%的時間裏掙到的，所以要把最重要、分數最多的章節，放在第一時間搞透徹。

很期待，一下就決定買，但翻譯得太痛苦瞭，光一個段落裏，幾句話反復硺磨，難解其易，就不能"大白話，通俗點嗎?

還不錯，適閤IT民工用

618活動很更給力，囤瞭一波

書籍封麵很有感覺，給同事買的，物流很快

封麵髒，下單到收貨13天，找瞭客服也不理！

首次接觸，感覺行文晦澀，

進階書籍，還沒開始看，戰略儲備

雖然不太看得懂，自己層次不夠吧