目 錄 第Ⅰ部分 領域驅動設計的原則與實踐第1章 什么是領域驅動設計 31.1 為復雜問題域創(chuàng)建軟件的挑戰(zhàn) 41.1.1 未使用通用語言創(chuàng)建的代碼 41.1.2 組織結構的缺乏 51.1.3 泥球模式將扼殺開發(fā) 51.1.4 缺乏對問題域的關注 51.2 領域驅動設計模式如何管理復雜性 61.2.1 DDD的戰(zhàn)略模式 61.2.2 DDD的戰(zhàn)術模式 81.2.3 問題空間與解空間 91.3 領域驅動設計的實踐與原則 101.3.1 專注于核心領域 101.3.2 通過協(xié)作進行學習 101.3.3 通過探索和實驗來創(chuàng)建模型 101.3.4 通信 111.3.5 理解模型的適用性 111.3.6 讓模型持續(xù)發(fā)展 111.4 領域驅動設計的常見誤區(qū) 121.4.1 戰(zhàn)術模式是DDD的關鍵 121.4.2 DDD是一套框架 121.4.3 DDD是一顆靈丹妙藥 121.5 要點 13第2章 提煉問題域 152.1 知識提煉與協(xié)作 152.1.1 通過通用語言達成共識 162.1.2 領域知識的重要性 172.1.3 業(yè)務分析員的角色 172.1.4 一個持續(xù)過程 172.2 與領域專家一起獲得領域見解 182.2.1 領域專家與業(yè)務相關人員的對比 182.2.2 對于業(yè)務的更深刻理解 182.2.3 與你的領域專家互動 192.3 有效提煉知識的模式 192.3.1 專注在最有意思的對話上 192.3.2 從用例開始 192.3.3 提出有力的問題 202.3.4 草圖 202.3.5 CRC卡 212.3.6 延遲對模型中概念的命名 212.3.7 行為驅動開發(fā) 212.3.8 快速成型 232.3.9 查看基于紙面的系統(tǒng) 232.4 查看現有模型 232.4.1 理解意圖 242.4.2 事件風暴 242.4.3 影響地圖 252.4.4 理解業(yè)務模型 262.4.5 刻意發(fā)現 272.4.6 模型探討漩渦 272.5 要點 28第3章 專注于核心領域 313.1 為何要分解一個問題域 313.2 如何捕獲問題的實質 323.2.1 超越需求 323.2.2 為達成什么是核心內容的共識而捕獲領域愿景 323.3 如何專注于核心問題 333.3.1 提煉問題域 343.3.2 核心領域 353.3.3 將你的核心領域當作一款產品而非一個項目 363.3.4 通用域 363.3.5 支撐域 373.4 子域如何決定解決方案的形成 373.5 并非一個系統(tǒng)的所有部分都會經過良好設計 383.5.1 專注于清晰邊界而非完美模型 383.5.2 一開始核心領域不必總是需要是完美的 393.5.3 構建用于替代而非重用的子域 393.6 如果沒有核心領域怎么辦 393.7 要點 39第4章 模型驅動設計 414.1 什么是領域模型 414.1.1 領域與領域模型的對比 424.1.2 分析模型 434.1.3 代碼模型 434.1.4 代碼模型是領域模型的主要表現 444.2 模型驅動設計 444.2.1 預先設計的挑戰(zhàn) 444.2.2 團隊建模 464.3 使用通用語言將分析和代碼模型綁定在一起 474.3.1 語言的生存周期將大于軟件 484.3.2 業(yè)務語言 484.3.3 開發(fā)人員和業(yè)務之間的轉譯 484.4 基于通用語言進行協(xié)作 494.4.1 通過使用具體示例來定制出語言 504.4.2 教導你的領域專家專注在問題上而不要跳到解決方案 504.4.3 塑造語言的最佳實踐 514.5 如何創(chuàng)建有效的領域模型 524.5.1 不要讓實情妨礙一個好模型 524.5.2 僅對相關內容建模 534.5.3 領域模型都是暫時有用的 534.5.4 要十分清楚專業(yè)術語 544.5.5 限制你的抽象 544.6 何時應用模型驅動設計 554.6.1 如果它不值得花費精力，則不要嘗試對其建模 564.6.2 專注于核心領域 564.7 要點 56第5章 領域模型實現模式 595.1 領域層 595.2 領域模型實現模式 605.2.1 領域模型 615.2.2 事務腳本 645.2.3 表模塊 675.2.4 活動記錄 675.2.5 貧血領域模型 675.2.6 貧血領域模型和函數編程 685.3 要點 71第6章 使用有界上下文維護領域模型的完整性 736.1 單個模型的挑戰(zhàn) 746.1.1 模型的復雜性可能會增加 746.1.2 多個團隊處理單個模型 746.1.3 模型語言中的歧義 756.1.4 領域概念的適用范圍 766.1.5 集成遺留代碼或第三方代碼 786.1.6 領域模型并非企業(yè)模型 786.2 使用有界上下文劃分和破除大模型 796.2.1 定義模型的邊界 816.2.2 子域和有界上下文之間的差異 846.3 實現有界上下文 856.4 要點 88第7章 上下文映射 917.1 一個現實情況的映射 927.1.1 技術的現實 927.1.2 組織的現實 937.1.3 映射一個相關現實情況 947.1.4 用X標記核心領域的位置 947.2 認識有界上下文之間的關系 947.2.1 防止損壞層 957.2.2 共享內核 967.2.3 開放宿主服務 967.2.4 分道揚鑣 977.2.5 合作關系 987.2.6 一種上游/下游關系 987.3 傳遞上下文映射 997.4 上下文映射的戰(zhàn)略重要性 1007.4.1 保持完整性 1007.4.2 解決計劃的基礎 1017.4.3 理解所有權和職責 1017.4.4 揭示業(yè)務工作流中的混亂區(qū)域 1017.4.5 識別非技術障礙 1017.4.6 鼓勵良好的溝通 1017.4.7 幫助加入的新員工 1027.5 要點 102第8章 應用程序架構 1038.1 應用程序架構 1038.1.1 分離應用程序的問題 1038.1.2 從領域的復雜性中進行抽象 1048.1.3 分層架構 1048.1.4 依賴倒置 1058.1.5 領域層 1058.1.6 應用程序服務層 1058.1.7 基礎架構層 1068.1.8 跨層通信 1068.1.9 隔離測試 1078.1.10 不要在有界上下文之間共享數據結構 1088.1.11 應用程序架構與用于有界上下文的架構的對比 1098.2 應用程序服務 1108.2.1 應用程序邏輯與領域邏輯的對比 1118.2.2 定義和公開能力 1128.2.3 業(yè)務用例協(xié)作 1128.2.4 應用程序服務表示的是用例，而不是創(chuàng)建、讀取、更新和刪除 1128.2.5 作為實現詳情的領域層 1138.2.6 領域報告 1138.2.7 讀取模型與事務模型的對比 1138.3 應用程序客戶端 1158.4 要點 117第9章 團隊開始應用領域驅動設計通常會遇到的問題 1199.1 過分強調戰(zhàn)術模式的重要性 1209.1.1 將相同架構用于所有的有界上下文 1209.1.2 力求戰(zhàn)術模式盡善盡美 1209.1.3 錯誤估計構造塊對于DDD的價值 1209.1.4 專注于代碼而非DDD的原則 1219.2 缺失了DDD的真實價值：協(xié)作、通信和上下文 1219.2.1 由于低估上下文的重要性而產生大泥球 1229.2.2 未能成功創(chuàng)建UL將造成歧義和誤解 1229.2.3 由于缺乏協(xié)作將只能設計專注于技術的解決方案 1239.3 在不重要的部分花費太多時間 1239.4 簡單問題復雜化 1239.4.1 將DDD原則應用到具有少量業(yè)務預期的瑣碎領域 1249.4.2 別將CRUD作為反模式 1249.4.3 將領域模型模式用于每一個有界上下文 1249.4.4 問一問自己：額外的復雜性是否值得 1249.5 低估應用DDD的成本 1259.5.1 嘗試在沒有積極專注的團隊的情況下取得成功 1259.5.2 項目背后沒有領域專家時的協(xié)作嘗試 1259.5.3 在非迭代式開發(fā)方法中進行學習 1259.5.4 將DDD應用到每一個問題 1269.5.5 為不必要的純粹性而犧牲實用主義 1269.5.6 尋求驗證會浪費精力 1269.5.7 永遠力求代碼之美 1279.5.8 DDD關乎的是提供價值 1279.6 要點 127第10章 應用DDD的原則、實踐與模式 12910.1 推廣使用DDD 12910.1.1 培訓團隊 13010.1.2 與業(yè)務人員進行交流 13010.2 應用DDD的原則 13110.2.1 理解愿景 13110.2.2 捕獲所需的行為 13110.2.3 理解環(huán)境的現實情況 13210.2.4 對解決方案建模 13310.3 探究和實驗 13910.3.1 質疑假設 13910.3.2 建模是一項持續(xù)性活動 13910.3.3 不存在錯誤的模型 14010.3.4 靈活的代碼有助于探索發(fā)現 14010.4 讓隱式內容變得顯式 14010.4.1 處理歧義 14110.4.2 為事物命名 14310.5 問題解決人先行，技術專家后行 14310.6 如何才能知道我在正確地工作 14310.6.1 好用就足夠了 14410.6.2 實踐、實踐、實踐 14410.7 要點 144第Ⅱ部分 戰(zhàn)略模式：在有界上下文之間通信第11章 有界上下文集成介紹 14911.1 如何集成有界上下文 15011.1.1 有界上下文是獨立自主的 15011.1.2 在代碼層面集成有界上下文的挑戰(zhàn) 15111.1.3 使用物理邊界來強制實現整潔的模型 15411.1.4 集成遺留系統(tǒng) 15511.2 集成分布式有界上下文 15811.2.1 集成用于分布式有界上下文的策略 15911.2.2 數據庫集成 15911.2.3 平面文件集成 16011.2.4 RPC 16111.2.5 消息傳遞 16211.2.6 REST 16211.3 DDD使用分布式系統(tǒng)的挑戰(zhàn) 16211.4 分布式事務將損害可擴展性和可靠性 16511.4.1 有界上下文不必彼此保持一致 16611.4.2 最終一致性 16611.5 事件驅動響應式DDD 16711.5.1 展示響應式解決方案的彈性和可擴展性 16811.5.2 異步消息傳遞的挑戰(zhàn)和取舍 16911.5.3 RPC還有價值嗎 16911.6 SOA和響應式DDD 17011.6.1 將你的有界上下文視作SOA服務 17111.6.2 進一步處理微服務架構 17411.7 要點 175第12章 通過消息傳遞集成 17712.1 消息傳遞基礎 17812.1.1 消息總線 17812.1.2 可靠的消息傳遞 18012.1.3 存儲轉發(fā) 18012.1.4 命令和事件 18012.1.5 最終一致性 18112.2 使用NServiceBus構建一個電子商務應用程序 18212.2.1 系統(tǒng)設計 18312.2.2 從Web應用程序發(fā)送命令 18712.2.3 處理命令和發(fā)布事件 19612.2.4 使用消息傳遞網關讓外部HTTP調用變得可靠 20312.2.5 實踐中的最終一致性 21112.2.6 有界上下文會存儲其本地所需的所有數據 21212.2.7 把所有內容都放在UI中 22012.3 維護消息傳遞應用程序 22312.3.1 消息版本管理 22312.3.2 監(jiān)控和擴展 22812.4 將有界上下文與公共傳輸集成 23112.4.1 消息傳遞橋 23212.4.2 公共傳輸 23312.5 要點 240第13章 通過使用RPC和REST的HTTP來集成 24113.1 為何選用HTTP 24213.1.1 沒有平臺耦合 24313.1.2 每個人都理解HTTP 24313.1.3 大量的成熟工具和庫 24313.1.4 內部測試你的API 24313.2 RPC 24413.2.1 在HTTP上實現RPC 24413.2.2 選擇一種RPC風格 25913.3 REST 26013.3.1 深入淺出地解釋REST 26013.3.2 用于有界上下文集成的REST 26313.3.3 維護REST應用程序 29713.3.4 將REST用于有界上下文集成的缺點 29813.4 要點 299第Ⅲ部分 戰(zhàn)術模式：創(chuàng)建有效的領域模型第14章 構造塊領域建模介紹 30314.1 戰(zhàn)術模式 30414.2 對領域建模的模式 30514.2.1 實體 30514.2.2 值對象 30814.2.3 領域服務 31014.2.4 模塊 31214.3 生命周期模式 31214.3.1 聚合 31214.3.2 工廠 31614.3.3 存儲庫 31614.4 顯露模式 31714.4.1 領域事件 31714.4.2 事件溯源 31914.5 要點 320第15章 值對象 32315.1 何時使用值對象 32415.1.1 表示描述性的、欠缺身份的概念 32415.1.2 增強明確性 32515.2 定義特征 32715.2.1 欠缺身份 32715.2.2 基于特性的相等性 32715.2.3 富含行為 33115.2.4 內聚 33115.2.5 不可變 33115.2.6 可組合性 33315.2.7 自驗證 33515.2.8 可測試 33815.3 常見的建模模式 33915.3.1 靜態(tài)工廠方法 33915.3.2 微類型 34115.3.3 規(guī)避集合 34315.4 持久化 34615.4.1 NoSQL 34615.4.2 SQL 34715.5 要點 354第16章 實體 35516.1 理解實體 35616.1.1 具有身份和連貫性的領域概念 35616.1.2 上下文依賴 35616.2 實現實體 35716.2.1 分配標識符 35716.2.2 將行為推入到值對象和領域服務中 36316.2.3 驗證并強制不變性 36516.2.4 專注于行為，而非數據 36816.2.5 避免“建?，F實世界”的謬誤 37116.2.6 分布式設計 37116.3 常見的實體建模原則和模式 37316.3.1 使用規(guī)范實現驗證和不變條件 37316.3.2 避免狀態(tài)模式；使用顯式建模 37616.3.3 避免將接收器和設置器與備忘錄模式結合使用 37916.3.4 選用無隱藏意外影響的功能 38016.4 要點 382第17章 領域服務 38317.1 理解領域服務 38417.1.1 何時使用領域服務 38417.1.2 領域服務解析 38817.1.3 避免使用貧血領域模型 38917.1.4 與應用程序服務對比 39017.2 利用領域服務 39017.2.1 服務層中 39017.2.2 領域中 39117.3 要點 397第18章 領域事件 39918.1 領域事件模式的實質 40018.1.1 已經發(fā)生了的重要領域事件 40018.1.2 響應事件 40118.1.3 可選的異步性 40118.1.4 內部事件與外部事件對比 40218.2 事件處理操作 40318.2.1 調用領域邏輯 40318.2.2 調用應用程序邏輯 40418.3 領域事件的實現模式 40418.3.1 使用.Net框架的事件模型 40418.3.2 使用內存中的總線 40618.3.3 Udi Dahan的DomainEvents靜態(tài)類 40918.3.4 返回領域事件 41218.3.5 使用IoC容器作為事件分發(fā)器 41518.4 測試領域事件 41618.4.1 單元測試 41618.4.2 應用服務層測試 41718.5 要點 419第19章 聚合 42119.1 管理復雜對象圖形 42219.1.1 選用單一遍歷方向 42219.1.2 合格的關聯關系 42419.1.3 選用ID而不是對象引用 42519.2 聚合 42819.2.1 圍繞領域不變條件進行設計 42919.2.2 高層次的領域抽象 42919.2.3 一致性邊界 42919.2.4 選用較小的聚合 43419.3 定義聚合邊界 43519.3.1 eBidder：在線拍賣案例研究 43519.3.2 與不變條件保持一致 43719.3.3 與事務和一致性保持一致 43919.3.4 忽略用戶界面影響 44019.3.5 避免無用的集合與容器 44119.3.6 不要專注于HAS-A關系 44119.3.7 重構聚合 44119.3.8 滿足業(yè)務用例——非現實環(huán)境 44119.4 實現聚合 44219.4.1 選擇一個聚合根 44219.4.2 引用其他聚合 44619.4.3 實現持久化 45019.4.4 實現事務一致性 45419.4.5 實現最終一致性 45519.4.6 實現并發(fā)性 45819.5 要點 459第20章 工廠 46120.1 工廠的作用 46120.1.1 從構造中分離出應用 46220.1.2 封裝內部事物 46220.1.3 隱藏創(chuàng)建類型的決策 46420.1.4 聚合上的工廠方法 46620.1.5 用于重構的工廠 46720.1.6 務實地使用工廠 46920.2 要點 469第21章 存儲庫 47121.1 存儲庫 47121.2 一種被誤解的模式 47321.2.1 存儲庫是一種反模式嗎 47321.2.2 領域模型和持久化模型之間的區(qū)別 47421.2.3 通用存儲庫 47521.3 聚合持久化策略 47721.3.1 使用能在不損壞領域模型的情況下將其映射到數據模型的持久化框架 47821.3.2 使用不能在不影響領域模型的情況下直接映射它的持久化框架 47821.3.3 公共接收器和設置器 47921.3.4 使用備忘錄模式 48021.3.5 事件流 48221.3.6 求真務實 48321.4 存儲庫是一個明確的約定 48321.5 事務管理和工作單元 48421.6 保存或不保存 48821.6.1 持久化追蹤領域對象變更的框架 48921.6.2 必須將變更顯式保存到聚合 49021.7 充當防止損壞層的存儲庫 49121.8 存儲庫的其他職責 49121.8.1 實體ID生成 49221.8.2 集合匯總 49421.8.3 并發(fā)性 49421.8.4 審計追蹤 49821.9 存儲庫反模式 49821.9.1 反模式：不要支持即席查詢 49821.9.2 反模式：延遲加載是一種設計異味 49921.9.3 反模式：不要為了報告需要而使用存儲庫 49921.10 存儲庫實現 49921.10.1 持久化框架可以在不損壞領域模型的情況下將其映射到數據模型 50021.10.2 持久化框架不能在不損壞領域模型的情況下直接映射領域模型 55021.11 要點 586第22章 事件溯源 58722.1 將狀態(tài)存儲為快照的限制 58822.2 通過將狀態(tài)存儲為事件流來獲得競爭優(yōu)勢 58922.2.1 時態(tài)查詢 58922.2.2 投影 59022.2.3 快照 59122.3 源自事件的聚合 59122.3.1 構造 59222.3.2 持久化與再融合 59622.4 構建一個事件存儲 60322.4.1 設計一種存儲格式 60422.4.2 創(chuàng)建事件流 60522.4.3 附加到事件流 60622.4.4 查詢事件流 60622.4.5 添加快照支持 60722.4.6 管理并發(fā)性 60922.4.7 一個基于SQL Server的事件存儲 61322.4.8 構建你自己的事件存儲是一個好主意嗎 61922.5 使用專門構建的Event Store 61922.5.1 安裝Greg Young的Event Store 61922.5.2 使用C#客戶端庫 62022.5.3 運行時態(tài)查詢 62422.5.4 創(chuàng)建投影 62722.6 使用事件溯源的CQRS 62922.6.1 使用投影創(chuàng)建視圖緩存 63022.6.2 CQRS和事件溯源協(xié)作 63022.7 簡要復述事件溯源的好處 63122.7.1 競爭性業(yè)務優(yōu)勢 63122.7.2 專注于表述性行為的聚合 63122.7.3 簡化的持久化 63222.7.4 更好的調試 63222.8 衡量事件溯源的代價 63222.8.1 版本控制 63222.8.2 要學習的新概念和要磨練的技能 63222.8.3 需要學習和掌握的新技術 63322.8.4 大量的數據存儲需求 63322.9 額外的學習資源 63322.10 要點 633第Ⅳ部分 有效應用程序的設計模式第23章 應用程序用戶界面的架構設計 63723.1 設計考量 63823.1.1 占有式UI與構成式UI的對比 63823.1.2 HTML API與數據API的對比 64023.1.3 客戶端與服務器端聚合/協(xié)作對比 64123.2 示例1：用于非分布式有界上下文的一個基于HTML API的、服務器端的UI 64323.3 示例2：用于分布式有界上下文的一個基于數據API的客戶端UI 65023.4 要點 658第24章 CQRS：一種有界上下文的架構 65924.1 為兩個上下文維護單個模型的挑戰(zhàn) 66024.2 用于復雜有界上下文的一種更好的架構 66124.3 命令端：業(yè)務任務 66224.3.1 顯式建模意圖 66224.3.2 不受展現干擾所影響的模型 66324.3.3 處理業(yè)務請求 66524.4 查詢端：領域報告 66524.4.1 直接映射到數據模型的報告 66624.4.2 從領域事件中構建的具體化視圖 66724.5 對CQRS的誤解 66824.5.1 CQRS很難 66824.5.2 CQRS是最終一致的 66824.5.3 模型需要源自事件 66924.5.4 命令應該是異步的 66924.5.5 CQRS僅適用于消息傳遞系統(tǒng) 66924.5.6 需要將CQRS用于領域事件 66924.6 可以擴展應用程序的模式 66924.6.1 擴展讀取端：一個最終一致的讀取模型 67024.6.2 擴展寫入端：使用異步命令 67224.6.3 對一切進行擴展 67324.7 要點 674第25章 命令：用于處理業(yè)務用例的應用程序服務模式 67725.1 區(qū)分應用程序邏輯和領域邏輯 67825.1.1 應用程序邏輯 67825.1.2 來自應用程序服務角度的領域邏輯 69025.2 應用程序服務模式 69025.2.1 命令處理程序 69025.2.2 發(fā)布/訂閱 69425.2.3 請求/回復模式 69625.2.4 async/await 69825.3 測試應用程序服務 69925.3.1 使用領域專業(yè)術語 69925.3.2 測試盡可能多的功能 70025.4 要點 702第26章 查詢：領域報告 70326.1 有界上下文中的領域報告 70426.1.1 從領域對象中派生報告 70426.1.2 直接訪問數據存儲 71026.1.3 從事件流構建投影 71626.2 跨有界上下文的領域報告 72326.2.1 復合UI 72326.2.2 單獨的報告上下文 72426.3 要點 726
鄂公網安備 42010302001612號 