現在是你最需要了解DDD的時刻了！
當你要把一個問題拆解處理時，DDD將會是你最大的幫手。本書最大的特色就是將整個DDD分成3大類。
第一大類為業務服務。
業務服務是全域分析的基本業務單元，在統一語言的指導下完成對業務需求的抽象，既可幫助我們辨識界限上下文，又可幫助開發團隊開展領域分析建模、領域設計建模和領域實現建模。業務服務的粒度也是服務契約的粒度，由此拉近了需求分析與軟體設計的距離，甚至可以說跨越了需求分析與軟體設計的鴻溝。
第二大類為菱形對稱架構。
雖然菱形對稱架構脫胎於六邊形架構與整潔架構，但它更為簡潔，與界限上下文的搭配可謂珠聯璧合，既保證了界限上下文作為基本架構單元的自治性，又融入了上下文映射的通訊模式，極大地豐富了設計要素的角色構造型。
第三大類為服務驅動設計。
服務驅動設計採用程序式的設計思維，卻又遵循物件導向的職責分配，能在提高設計品質的同時降低開發團隊的設計門檻，完成從領域分析模型到領域實現模型的無縫轉換，並可作為測試驅動開發的前奏，讓領域邏輯的實現變得更加穩健而高效。
本書特色：●將整個DDD分成3大類
〇破解軟體複雜度的新觀念，讓你不被程式碼糾纏人生
●了解問題空間和解答空間的觀念
〇用5個W來探索問題空間，先分析業務流程再開始設計
●充分了解Entity、Value Object、Service、Module、Factory、Repository、Aggregate和Domain Event
〇動手實作領域設計的建模、領域實現建模
●融合現在的設計團隊，建立領域驅動模型的戰略
作者簡介：
張逸
高品質編碼實踐者、領域驅動設計佈道師、微服務系統架構師、大數據平台架構師、敏捷轉型諮詢師，曾就職於中興通訊、惠普、思特沃克（ThoughtWorks）、民航（成都）信息等企業，致力於大型軟體企業的分佈式架構設計、領域驅動設計、大數據平台架構設計以及垂直領域的企業架構規劃與建設，並為國內外多家企業提供技術培訓與諮詢服務。
作者序
寫下本書第一個字的具體時間已不可考。從文件創建的時間看，本書的寫作至少可以追溯到2017 年11 月，屈指算來，三載光陰已逝。為了本書，我已算得上嘔心瀝血。回想這三年多時光，無論是在萬公尺高空的飛行途中，還是在蔚藍海邊的旅行路上，抑或工作之餘正襟危坐於書桌之前，我的心弦一刻不敢放鬆，時刻沉思系統的建構，糾結案例的選擇，反覆推敲文字的運用。我力求輸出最好的內容，希望打造領域驅動設計技術書籍的經典！
我在ThoughtWorks 的前同事滕雲開我的玩笑：「老人家，你寫完這本書，也就功德圓滿了！」、「老人家」是我在ThoughtWorks 的諢名。我雖然對此稱呼一直敬謝不敏，不過寫作至今，我已心力交瘁，被稱作「老人家」，也算「名副其實」了。至於是否「功德圓滿」，就要交給讀者諸君來品評了。
本書內容主要來自我在GitChat 發佈的課程「領域驅動設計實踐」。該課程歷經兩年打造，完成於2020 年1 月21 日。當時的我，頗有感慨地寫下如此後記：
課程寫作結束了。戰略篇一共34 章，約15.5 萬字；戰術篇一共71 章，約35.1 萬字。合計105 章，50.6 餘萬字，加上2 篇訪談錄、2 篇開篇詞與這篇可以稱為「寫後感」的後記，共110 章。如此成果也足可慰藉我為之付出的兩年多的艱辛時光！
我對「領域驅動設計實踐」課程的內容還算滿意，然而，隨著我對領域驅動設計的了解的蛻變與昇華，我的「野心」也在不斷膨脹，我不僅希望講清楚應該如何實踐領域驅動設計，還企圖對這套方法區塊系進行深層次的解構。
所謂「解構」，就是解析與重構：
解析，就是要做到知其然更知其所以然；
重構，則要做到青出於藍而勝於藍。
我欽佩並且尊敬Eric Evans 對領域驅動設計革命性的創造，他對設計的洞見讓我尊敬不已。尤其在徹底吃透界限上下文的本質之後，微服務又蔚然成風，我更加佩服他的遠見卓識。然而，尊敬不是膜拜，佩服並非盲從，在實踐領域驅動設計的過程中，我確實發現了這套方法區塊系天生的不足。於是，我在本書中提出了我的GitChat 課程不曾涵蓋的領域驅動設計統一過程（domain-driven design unified process，DDDUP），相當於我站在巨人Eric Evans 的肩膀上，建構了自己的一套領域驅動設計知識系統。
領域驅動設計統一過程的提出，從根基上改變了本書的結構。我調整和整理了本書的寫作脈絡，讓本書呈現出與「領域驅動設計實踐」課程迥然有別的全新面貌。本書不再滿足於粗略地將內容劃分為戰略篇和戰術篇，而是在領域驅動設計統一過程的指導下，將該過程的3 個階段—全域分析、架構映射和領域建模作為本書的3 個核心篇，再輔以開篇和融合，共分為5 篇（20 章）和4 個附錄，全面而完整地表達了我對領域驅
動設計的全部認知與最佳實踐。在對內容做進一步精簡後，本書仍然接近600 頁，算得上是軟體技術類別的大部頭了。
該如何閱讀這樣一本厚書呢？
若你時間足夠充裕，又渴望徹底探索領域驅動設計的全貌，我建議還是按部就班、循序漸進地進行閱讀。或許在閱讀開篇的3 章時，你會因為太多資訊的一次性湧入而產生迷惑、困擾和不解，這只是因為我期望率先為讀者呈現領域驅動設計的整體面貌。在獲得領域驅動設計的全貌之後，哪怕你只是在腦海中存留了一個朦朧的輪廓，也足以開啟自己對設計細節的了解和認識。
若你追求高效閱讀，又渴望尋求領域驅動設計問題的答案，可以根據目錄精準定位你最為關心的技術講解。或許你會失望，甚至產生質疑，從目錄中你獲得了太多全新的概念，而這些概念從未見於任何一本領域驅動設計的圖書，這是因為這些概念都是我針對領域驅動設計提出的改進與補充，是我解構全新領域驅動設計知識系統的得意之筆—要不然，一本技術圖書怎麼會寫三年之久呢？
我將自鳴得意的創新概念一一羅列於此。
業務服務。
業務服務是全域分析的基本業務單元，在統一語言的指導下完成對業務需求的抽象，既可幫助我們辨識界限上下文，又可幫助開發團隊開展領域分析建模、領域設計建模和領域實現建模。業務服務的粒度也是服務契約的粒度，由此拉近了需求分析與軟體設計的距離，甚至可以說跨越了需求分析與軟體設計的鴻溝。
菱形對稱架構。
雖然菱形對稱架構脫胎於六邊形架構與整潔架構，但它更為簡潔，與界限上下文的搭配可謂珠聯璧合，既保證了界限上下文作為基本架構單元的自治性，又融入了上下文映射的通訊模式，極大地豐富了設計要素的角色構造型。
服務驅動設計。
服務驅動設計採用程序式的設計思維，卻又遵循物件
導向的職責分配，能在提高設計品質的同時降低開發團隊的設計門檻，完成從領域分析模型到領域實現模型的無縫轉換，並可作為測試驅動開發的前奏，讓領域邏輯的實現變得更加穩健而高效。
以上概念皆為領域驅動設計統一過程的設計專案，又都能與領域驅動設計的固有模式有機融合。對軟體複雜度成因的剖析，對價值需求和業務需求的劃分，在領域驅動設計統一過程基礎上建立的能力評估模型與參
考過程模型，提出的諸多新概念、新方法、新模式、新系統，雖說都出自我的一孔之見，但也確乎來自我的第一線實踐和複習，我自覺其可圈可點。至於內容的優劣，還是交給讀者評判吧。
若讀者在閱讀本書時有任何意見與回饋，可關注我的微信公眾號「逸言」與我取得聯繫，我也會在公眾號上發佈後續我對領域驅動設計系統的更多探索與思考，也歡迎讀者加入我的知識星球"NoDDD"，與我共同
探討軟體技術的二三事。
在寫這篇前言的前一天，我偶然讀到蘇東坡的一首小詞：
春未老，風細柳斜斜。試上超然台上看，半壕春水一城花。煙雨暗千家。
寒食後，酒醒卻諮嗟。休對故人思故國，且將新火試新茶。詩酒趁年華。
驀然內心被叩擊，仿佛心弦被優美的辭章輕輕地帶著詩意撥弄。吾身雖不能上超然台，然而書成之後，可否看到半壕春水一城花？未曾飲酒，卻諮嗟，是否多情笑我早生華髮？如今的我，已然焙出新火，恰當新火試新茶，卻不知待到明年春未老時，能否做到何妨吟嘯且徐行的落拓不羈？無論如何，還當詩酒趁年華—仰天大笑出門去，吾輩豈是蓬蒿人！
張逸
寫下本書第一個字的具體時間已不可考。從文件創建的時間看，本書的寫作至少可以追溯到2017 年11 月，屈指算來，三載光陰已逝。為了本書，我已算得上嘔心瀝血。回想這三年多時光，無論是在萬公尺高空的飛行途中，還是在蔚藍海邊的旅行路上，抑或工作之餘正襟危坐於書桌之前，我的心弦一刻不敢放鬆，時刻沉思系統的建構，糾結案例的選擇，反覆推敲文字的運用。我力求輸出最好的內容，希望打造領域驅動設計技術書籍的經典！
我在ThoughtWorks 的前同事滕雲開我的玩笑：「老人家，你寫完這本書，也就功德圓滿了！」、「老人家」是我在Thoug...
目錄
第一篇 開篇
01 軟體複雜度剖析
1.1 什麼是複雜系統
1.2 了解能力
1.3 預測能力
02 領域驅動設計概覽
2.1 領域驅動設計的基本概念
2.2 領域驅動設計過程
2.3 控制軟體複雜度
2.4 冷靜認識
03 領域驅動設計統一過程
3.1 領域驅動設計現存的不足
3.2 領域驅動設計統一過程
第二篇 全域分析
04 問題空間探索
4.1 全域分析的5W 模型
4.2 高效溝通
4.3 高效協作
05 價值需求分析
5.1 辨識利益相關者
5.2 明確系統願景
5.3 確定系統範圍
5.4 使用商業模式畫布
06 業務需求分析
6.1 業務流程
6.2 業務場景
6.3 子領域
第三篇 架構映射
07 同構系統
7.1 概念層次的同構系統
7.2 設計層次的同構系統
7.3 管理層次的同構系統
08 系統上下文
8.1 「系統內」和「系統外」
8.2 系統上下文
8.3 系統上下文的確定
09 界限上下文
9.1 界限上下文的定義
9.2 界限上下文的特徵
9.3 界限上下文的辨
10 上下文映射
10.1 上下文映射概述
10.2 通訊整合模式
10.3 團隊協作模式
10.4 上下文映射的設計錯誤
10.5 上下文映射的確定
11 服務契約設計
11.1 訊息契約
11.2 服務契約
11.3 設計服務契約
12 領域驅動架構
12.1 菱形對稱架構
12.2 系統分層架構
12.3 領域驅動架構風格
第四篇 領域建模
13 模型驅動設計
13.1 軟體系統中的模型
13.2 模型驅動設計
13.3 領域模型驅動設計
14 領域分析建模
14.1 統一語言與領域分析模型
14.2 快速建模法
14.3 領域分析模型的精煉
14.4 領域分析模型與界限上下文
15 領域模型設計要素
15.1 領域設計模型
15.2 實體
15.3 值物件
15.4 聚合
15.5 聚合生命週期的管理
15.6 領域服務
15.7 領域事件
16 領域設計建模
16.1 角色構造型
16.2 設計聚合
16.3 服務驅動設計
17 領域實現建模
17.1 穩定的領域模型
17.2 測試優先的領域實現建模
17.3 領域建模過程
17.3.1 薪資管理系統的需求
第五篇 融合
18 領域驅動設計的戰略考量
18.1 界限上下文與微服務
18.2 界限上下文之間的分散式通訊
18.3 命令查詢職責的分離
18.4 交易
19 領域驅動設計的戰術考量
19.1 設計概念的統一語言
19.2 領域模型的持久化
19.3 資源庫的實現
20 領域驅動設計系統
20.1 領域驅動設計的精髓
20.2 領域驅動設計能力評估模型
20.3 領域驅動設計參考過程模型
20.4 複習
附錄
A 領域建模範式
A.1 結構建模範式
A.2 物件建模範式
A.3 函數建模範式
B 事件驅動模型
B.1 事件風暴
B.2 事件溯源模式
B.3 事件驅動架構
C 領域驅動設計魔方
C.1 發展過程的里程碑
C.2 領域驅動設計魔方
C.3 全域分析的魔方切面
C.4 架構映射的魔方切面
C.5 領域建模
D 領域驅動設計統一過程發表物
全域分析規格說明書
架構映射戰略設計方案
E 參考文獻
第一篇 開篇
01 軟體複雜度剖析
1.1 什麼是複雜系統
1.2 了解能力
1.3 預測能力
02 領域驅動設計概覽
2.1 領域驅動設計的基本概念
2.2 領域驅動設計過程
2.3 控制軟體複雜度
2.4 冷靜認識
03 領域驅動設計統一過程
3.1 領域驅動設計現存的不足
3.2 領域驅動設計統一過程
第二篇 全域分析
04 問題空間探索
4.1 全域分析的5W 模型
4.2 高效溝通
4.3 高效協作
05 價值需求分析
5.1 辨識利益相關者
5.2 明確系統願景
5.3 確定系統範圍
5.4 使用商業模式畫布
06 業務需求分析
6.1 業務流程
6.2 業務場景
6...
購物須知
退換貨說明：
會員均享有10天的商品猶豫期（含例假日）。若您欲辦理退換貨，請於取得該商品10日內寄回。
辦理退換貨時，請保持商品全新狀態與完整包裝（商品本身、贈品、贈票、附件、內外包裝、保證書、隨貨文件等）一併寄回。若退回商品無法回復原狀者，可能影響退換貨權利之行使或須負擔部分費用。
訂購本商品前請務必詳閱退換貨原則。
收藏
2024專利防護中