第一部分 讓領域模型發揮作用
第1章 消化知識
1.1 有效建模的要素
1.2 知識消化
1.3 持續學習
1.4 知識豐富的設計
1.5 深層模型
第2章 語言的交流和使用
2.1 模式：UBIQUITOUS LANGUAGE
2.2 “大聲地”建模
2.3 一個團隊，一種語言
2.4 文檔和圖
2.4.1 書麵設計文檔
2.4.2 完全依賴可執行代碼的情況
2.5 解釋性模型
第3章 綁定模型和實現
3.1 模式：MODEL-DRIVEN DESIGN
3.2 建模範式和工具支持
3.3 揭示主旨：為什麼模型對用戶至關重要
3.4 模式：HANDS-ON MODELER
第二部分 模型驅動設計的構造塊
第4章 分離領域
4.1 模式：LAYERED ARCHITECTURE
4.1.1 將各層關聯起來
4.1.2 架構框架
4.2 模型屬於領域層
4.3 模式：THE SMART UI“ANTI-PATTERN”
4.4 其他分離方式
第5章 軟件中所錶示的模型
5.1 關聯
5.2 模式：ENTITY（又稱為REFERENCE OBJECT）
5.2.1 ENTITY建模
5.2.2 設計標識操作
5.3 模式：VALUE OBJECT
5.3.1 設計VALUE OBJECT
5.3.2 設計包含VALUE OBJECT的關聯
5.4 模式：SERVICE
5.4.1 SERVICE與孤立的領域層
5.4.2 粒度
5.4.3 對SERVICE的訪問
5.5 模式：ＭODULE（也稱為PACKAGE）
5.5.1 敏捷的MODULE
5.5.2 基礎設施驅動的打包存在的隱患
5.6 建模範式
5.6.1 對象範式流行的原因
5.6.2 對象世界中的非對象
5.6.3 在混閤範式中堅持使用MODEL-DRIVEN DESIGN
第6章 領域對象的生命周期
6.1 模式：AGGREGATE
6.2 模式：FACTORY
6.2.1 選擇FACTORY及其應用位置
6.2.2 有些情況下隻需使用構造函數
6.2.3 接口的設計
6.2.4 固定規則的邏輯應放置在哪裏
6.2.5 ENTITY FACTORY與VALUE OBJECT FACTORY
6.2.6 重建已存儲的對象
6.3 模式：REPOSITORY
6.3.1 REPOSITORY的查詢
6.3.2 客戶代碼可以忽略REPOSITORY的實現，但開發人員不能忽略
6.3.3 REPOSITORY的實現
6.3.4 在框架內工作
6.3.5 REPOSITORY與FACTORY的關係
6.4 為關係數據庫設計對象
第7章 使用語言：一個擴展的示例
7.1 貨物運輸係統簡介
7.2 隔離領域：應用程序的引入
7.3 將ENTITY和VALUE OBJECT區彆開
7.4 設計運輸係統中的關聯
7.5 AGGREGATE邊界
7.6 選擇REPOSITORY
7.7 場景走查
7.7.1 應用程序特性舉例：更改Cargo的目的地
7.7.2 應用程序特性舉例：重復業務
7.8 對象的創建
7.8.1 Cargo的FACTORY和構造函數
7.8.2 添加一個Handling Event
7.9 停下來重構：Cargo AGGREGATE的另一種設計
7.10 運輸模型中的ＭODULE
7.11 引入新特性：配額檢查
7.11.1 連接兩個係統
7.11.2 進一步完善模型：劃分業務
7.11.3 性能優化
7.12 小結
第三部分 通過重構來加深理解
第8章 突破
8.1 一個突破的故事
8.1.1 華而不實的模型
8.1.2 突破
8.1.3 更深層模型
8.1.4 冷靜決策
8.1.5 成果
8.2 機遇
8.3 關注根本
8.4 後記：越來越多的新理解
第9章 將隱式概念轉變為顯式概念
9.1 概念挖掘
9.1.1 傾聽語言
9.1.2 檢查不足之處
9.1.3 思考矛盾之處
9.1.4 查閱書籍
9.1.5 嘗試，再嘗試
9.2 如何為那些不太明顯的概念建模
9.2.1 顯式的約束
9.2.2 作為領域對象的過程
9.2.3 模式：SPECIFICATION
9.2.4 SPECIFICATION的應用和實現
第10章 柔 性 設 計
10.1 模式：INTENTION-REVEALING INTERFACES
10.2 模式：SIDE-EFFECT-FREE FUNCTION
10.3 模式：ASSERTION
10.4 模式：CONCEPTUAL CONTOUR
10.5 模式：STANDALONE CLASS
10.6 模式：CLOSURE OF OPERATION
10.7 聲明式設計
10.8 聲明式設計風格
10.9 切入問題的角度
10.9.1 分割子領域
10.9.2 盡可能利用已有的形式
第11章 分析模式的應用
第12章 將設計模式應用於模型
12.1 模式：STRATEGY（也稱為POLICY）
12.2 模式：COMPOSITE
12.3 為什麼沒有介紹FLYWEIGHT
第13章 通過重構得到更深層的理解
13.1 開始重構
13.2 探索團隊
13.3 藉鑒先前的經驗
13.4 針對開發人員的設計
13.5 重構的時機
13.6 危機就是機遇
第四部分 戰略設計
第14章 保持模型的完整性
14.1 模式：BOUNDED CONTEXT
14.2 模式：CONTINUOUS INTEGRATION
14.3 模式：CONTEXT MAP
14.3.1 測試CONTEXT的邊界
14.3.2 CONTEXT MAP的組織和文檔化
14.4 BOUNDED CONTEXT之間的關係
14.5 模式：SHARED KERNEL
14.6 模式：CUSTOMER/SUPPLIERDEVELOPMENT TEAM
14.7 模式：CONFORMIST
14.8 模式：ANTICORRUPTION LAYER
14.8.1 設計ANTICORRUPTION LAYER的接口
14.8.2 實現ANTICORRUPTION LAYER
14.8.3 一個關於防禦的故事
14.9 模式：SEPARATE WAY
14.10 模式：OPEN HOST SERVICE
14.11 模式：PUBLISHED LANGUAGE
14.12 “大象”的統一
14.13 選擇你的模型上下文策略
14.13.1 製定團隊決策或更高層的決策
14.13.2 在上下文中工作
14.13.3 轉換邊界
14.13.4 接受那些我們無法更改的事物：描述外部係統
14.13.5 與外部係統的關係
14.13.6 正在設計的係統
14.13.7 滿足不同模型的特殊需要
14.13.8 部署
14.13.9 權衡
14.13.10 當項目正在進行時
14.14 轉換
14.14.1 閤並CONTEXT：SEPARATE WAY →SHARED KERNEL
14.14.2 閤並CONTEXT：SHARED KERNEL→CONTINUOUS INTEGRATION
14.14.3 逐步淘汰遺留係統
14.14.4 OPEN HOST SERVICE→PUBLISHED LANGUAGE
第15章 精煉
15.1 模式：CORE DOMAIN
15.1.1 選擇核心
15.1.2 工作的分配
15.2 精煉的逐步提升
15.3 模式：GENERIC SUBDOMAIN
15.3.1 通用不等於可以重用
15.3.2 項目風險管理
15.4 模式：DOMAIN VISION STATEMENT
15.5 模式：HIGHLIGHTED CORE
15.5.1 精煉文檔
15.5.2 標明CORE
15.5.3 把精煉文檔作為過程工具
15.6 模式：COHESIVE MECHANISM
15.6.1 GENERIC SUBDOMAIN與COHE-SIVE MECHANISM的比較
15.6.2 MECHANISM是CORE DOMAIN一部分
15.7 通過精煉得到聲明式風格
15.8 模式：SEGREGATED CORE
15.8.1 創建SEGREGATED CORE的代價
15.8.2 不斷發展演變的團隊決策
15.9 模式：ABSTRACT CORE
15.10 深層模型精煉
15.11 選擇重構目標
第16章 大比例結構
16.1 模式：EVOLVING ORDER
16.2 模式：SYSTEM METAPHOR
16.3 模式：RESPONSIBILITY LAYER
16.4 模式：KNOWLEDGE LEVEL
16.5 模式：PLUGGABLE COMPONENT FRAMEWORK
16.6 結構應該有一種什麼樣的約束
16.7 通過重構得到更適當的結構
16.7.1 最小化
16.7.2 溝通和自律
16.7.3 通過重構得到柔性設計
16.7.4 通過精煉可以減輕負擔
第17章 領域驅動設計的綜閤運用
17.1 把大比例結構與BOUNDED CONTEXT結閤起來使用
17.2 將大比例結構與精煉結閤起來使用
17.3 首先評估
17.4 由誰製定策略
17.4.1 從應用程序開發自動得齣的結構
17.4.2 以客戶為中心的架構團隊
17.5 製定戰略設計決策的6個要點
17.5.1 技術框架同樣如此
17.5.2 注意總體規劃
結束語
附錄
術語錶
參考文獻
圖片說明
索引
· · · · · · (
收起)
