●目錄 部分  運用領域模型 章  消化知識  5 1.1  有效建模的要素  9 1.2  知識消化  10 1.3  持續學習  11 1.4  知識豐富的設計  12 1.5  深層模型  15 第2章  交流與語言的使用  16 2.1  模式：UBIQUITOUS LANGUAGE  16 2.2  “大聲地”建模  21 2.3  一個團隊，一種語言  22 2.4  文檔和圖  24 2.4.1  書面設計文檔  25 2.4.2  完全依賴可執行代碼的情況  27 2.5  解釋性模型  27 第3章  綁定模型和實現  29 3.1  模式：MODEL-DRIVEN DESIGN  30 3.2  建模範式和工具支持  32 3.3  揭示主旨：為什麼模型對用戶至關重要  38 3.4  模式：HANDS-ON MODELER  39 第二部分  模型驅動設計的構造塊 第4章  分離領域  43 4.1  模式：LAYERED ARCHITECTURE  43 4.1.1  將各層關聯起來  46 4.1.2  架構框架  47 4.2  領域層是模型的精髓  48 4.3  模式：THE SMART UI“反模式”  48 4.4  其他分離方式  50 第5章  軟件中所表示的模型  51 5.1  關聯  52 5.2  模式：ENTITY（又稱為REFERENCE OBJECT）  56 5.2.1  ENTITY建模  59 5.2.2  設計標識操作  60 5.3  模式：VALUE OBJECT  62 5.3.1  設計VALUE OBJECT  64 5.3.2  設計包含VALUE OBJECT的關聯  67 5.4  模式：SERVICE  67 5.4.1  SERVICE與孤立的領域層  69 5.4.2  粒度  70 5.4.3  對SERVICE的訪問  70 5.5  模式：ＭODULE（也稱為PACKAGE）  71 5.5.1  敏捷的MODULE  72 5.5.2  通過基礎設施打包時存在的隱患  73 5.6  建模範式  75 5.6.1  對像範式流行的原因  76 5.6.2  對像世界中的非對像  77 5.6.3  在混合範式中堅持使用MODEL-DRIVEN DESIGN  78 第6章  領域對像的生命周期  80 6.1  模式：AGGREGATE  81 6.2  模式：FACTORY  89 6.2.1  選擇FACTORY及其應用位置  91 6.2.2  有些情況下隻需使用構造函數  93 6.2.3  接口的設計  94 6.2.4  固定規則的相關邏輯應放置在哪裡  94 6.2.5  ENTITY FACTORY與VALUE OBJECT FACTORY  95 6.2.6  重建已存儲的對像  95 6.3  模式：REPOSITORY  97 6.3.1  REPOSITORY的查詢  101 6.3.2  客戶代碼可以忽略REPOSITORY的實現，但開發人員不能忽略  102 6.3.3  REPOSITORY的實現  103 6.3.4  在框架內工作  104 6.3.5  REPOSITORY與FACTORY的關繫  104 6.4  為關繫數據庫設計對像  106 第7章  使用語言：一個擴展的示例  108 7.1  貨物運輸繫統簡介  108 7.2  隔離領域：引入應用層  110 7.3  將ENTITY和VALUE OBJECT區別開  110 7.4  設計運輸領域中的關聯  112 7.5  AGGREGATE邊界  113 7.6  選擇REPOSITORY  113 7.7  場景走查  115 7.7.1  應用程序特性舉例：更改Cargo的目的地  115 7.7.2  應用程序特性舉例：重復業務  116 7.8  對像的創建  116 7.8.1  Cargo的FACTORY和構造函數  116 7.8.2  添加Handling Event  117 7.9  停一下，重構：Cargo AGGREGATE 的另一種設計  118 7.10  運輸模型中的ＭODULE  120 7.11  引入新特性：配額檢查  122 7.11.1  連接兩個繫統  123 7.11.2  進一步完善模型：劃分業務  124 7.11.3  性能優化  125 7.12  小結  126 第三部分  通過重構來加深理解 第8章  突破  131 8.1  一個關於突破的故事  131 8.1.1  華而不實的模型  132 8.1.2  突破  133 8.1.3  更深層模型  135 8.1.4  冷靜決策  137 8.1.5  成果  138 8.2  機遇  138 8.3  關注根本  138 8.4  後記：越來越多的新理解  139 第9章  將隱式概念轉變為顯式概念  140 9.1  概念挖掘  140 9.1.1  傾聽語言  140 9.1.2  檢查不足之處  144 9.1.3  思考矛盾之處  148 9.1.4  查閱書籍  148 9.1.5  嘗試，再嘗試  150 9.2  如何為那些不太明顯的概念建模  150 9.2.1  顯式的約束  151 9.2.2  將過程建模為領域對像  153 9.2.3  模式：SPECIFICATION  154 9.2.4  SPECIFICATION的應用和實現  156 0章  柔 性 設 計  168 10.1  模式：INTENTION-REVEALING INTERFACES  169 10.2  模式：SIDE-EFFECT-FREE FUNCTION  173 10.3  模式：ASSERTION  177 10.4  模式：CONCEPTUAL CONTOUR  181 10.5  模式：STANDALONE CLASS  184 10.6  模式：CLOSURE OF OPERATION  186 10.7  聲明式設計  188 10.8  聲明式設計風格  190 10.9  切入問題的角度  197 10.9.1  分割子領域  197 10.9.2  盡可能利用已有的形式  198 1章  應用分析模式  206 2章  將設計模式應用於模型  217 12.1  模式：STRATEGY（也稱為POLICY）  218 12.2  模式：COMPOSITE  221 12.3  為什麼沒有介紹FLYWEIGHT  226 3章  通過重構得到更深層的理解  227 13.1  開始重構  227 13.2  探索團隊  227 13.3  借鋻先前的經驗  228 13.4  針對開發人員的設計  229 13.5  重構的時機  229 13.6  危機就是機遇  230 第四部分  戰略設計 4章  保持模型的完整性  233 14.1  模式：BOUNDED CONTEXT  235 14.2  模式：CONTINUOUS INTEGRATION  239 14.3  模式：CONTEXT MAP  241 14.3.1  測試CONTEXT的邊界  247 14.3.2  CONTEXT MAP的組織和文檔化  247 14.4  BOUNDED CONTEXT之間的關繫  248 14.5  模式：SHARED KERNEL  248 14.6  模式：CUSTOMER/SUPPLIER DEVELOPMENT TEAM  250 14.7  模式：CONFORMIST  253 14.8  模式：ANTICORRUPTION LAYER  255 14.8.1  設計ANTICORRUPTION LAYER的接口  256 14.8.2  實現ANTICORRUPTION LAYER  256 14.8.3  一個關於防御的故事  259 14.9  模式：SEPARATE WAY  260 14.10  模式：OPEN HOST SERVICE  261 14.11  模式：PUBLISHED LANGUAGE  262 14.12  “大像”的統一  264 14.13  選擇你的模型上下文策略  267 14.13.1  團隊決策或更高層決策  268 14.13.2  置身上下文中  268 14.13.3  轉換邊界  268 14.13.4  接受那些我們無法更改的事物：描述外部繫統  269 14.13.5  與外部繫統的關繫  269 14.13.6  設計中的繫統  270 14.13.7  用不同模型滿足特殊需要  270 14.13.8  部署  271 14.13.9  權衡  271 14.13.10  當項目正在進行時  272 14.14  轉換  272 14.14.1  合並CONTEXT：SEPARATE WAY →SHARED KERNEL  273 14.14.2  合並CONTEXT：SHARED KERNEL→CONTINUOUS INTEGRATION  274 14.14.3  逐步淘汰遺留繫統  275 14.14.4  OPEN HOST SERVICE→PUBLISHED LANGUAGE  276 5章  精煉  277 15.1  模式：CORE DOMAIN  278 15.1.1  選擇核心  280 15.1.2  工作的分配  280 15.2  精煉的逐步提升  281 15.3  模式：GENERIC SUBDOMAIN  282 15.3.1  通用不等於可重用  286 15.3.2  項目風險管理  287 15.4  模式：DOMAIN VISION STATEMENT  287 15.5  模式：HIGHLIGHTED CORE  289 15.5.1  精煉文檔  289 15.5.2  標明CORE  290 15.5.3  把精煉文檔作為過程工具  291 15.6  模式：COHESIVE MECHANISM  292 15.6.1  GENERIC SUBDOMAIN與COHESIVE MECHANISM的比較  293 15.6.2  MECHANISM是CORE DOMAIN一部分  294 15.7  通過精煉得到聲明式風格  294 15.8  模式：SEGREGATED CORE  295 15.8.1  創建SEGREGATED CORE的代價  296 15.8.2  不斷發展演變的團隊決策  296 15.9  模式：ABSTRACT CORE  301 15.10  深層模型精煉  302 15.11  選擇重構目標  302 6章  大型結構  303 16.1  模式：EVOLVING ORDER  306 16.2  模式：SYSTEM METAPHOR  308 16.3  模式：RESPONSIBILITY LAYER  309 16.4  模式：KNOWLEDGE LEVEL  321 16.5  模式：PLUGGABLE COMPONENT FRAMEWORK  328 16.6  結構應該有一種什麼樣的約束  332 16.7  通過重構得到更適當的結構  333 16.7.1  最小化  333 16.7.2  溝通和自律  334 16.7.3  通過重構得到柔性設計  334 16.7.4  通過精煉可以減輕負擔  334 7章  領域驅動設計的綜合運用  336 17.1  把大型結構與BOUNDED CONTEXT結合起來使用  336 17.2  將大型結構與精煉結合起來使用  339 17.3  首先評估  339 17.4  由誰制定策略  341 17.4.1  從應用程序開發自動得出的結構  341 17.4.2  以客戶為中心的架構團隊  341 17.5  制定戰略設計決策的6個要點  342 17.5.1  技術框架同樣如此  344 17.5.2  注意總體規劃  345 結束語 附錄  351 術語表  354 參考文獻  357 圖片說明  359 索引  360