Python設計模式

目錄
前言 1
第0 章 概述 11
第一部分 構建支持領域模型的架構
第1 章 領域建模 23
1.1 什么是領域模型 24
1.2 探索領域語言 .27
1.3 單元測試領域模型 28
1.3.1 數(shù)據(jù)類非常適合值對象 34
1.3.2 值對象和實體 36
1.4 并非一切都必須是對象：領域服務函數(shù) 38
1.4.1 基于Python 的魔法方法利用Python 使用我們的模型 39
1.4.2 異常也可以表達領域概念 40
第2 章 存儲庫模式 43
2.1 持久化我們的領域模型 .44
2.2 一些偽代碼：我們需要什么 44
2.3 將DIP 應用于數(shù)據(jù)訪問 .45
2.4 回顧：我們的模型 47
2.4.1 一般的ORM 方式：模型依賴于ORM 47
2.4.2 反轉依賴關系：ORM 依賴于模型 .49
2.5 介紹存儲庫模式 52
2.5.1 抽象的存儲庫 53
2.5.2 什么是權衡 54
2.6 構建用于測試的假存儲庫現(xiàn)在變得微不足道 .58
2.7 在Python 中，什么是端口和適配器 59
2.8 總結 .60
第3 章 一個簡要的插曲：關于耦合和抽象 .63
3.1 抽象狀態(tài)有助于增加可測試性 64
3.2 選擇正確的抽象 68
3.3 實現(xiàn)我們所選擇的抽象 .69
3.3.1 使用偽造和依賴注入進行邊緣到邊緣測試 72
3.3.2 為什么不直接修補呢.74
3.4 總結 .77
第4 章 我們的第一個用例：Flask API 和服務層 79
4.1 將我們的應用程序連接到真實世界.81
4.2 第一個端到端測試 81
4.3 直接實現(xiàn)83
4.4 需要數(shù)據(jù)庫檢查的錯誤條件 84
4.5 引入服務層，并使用FakeRepository 對其進行單元測試 86
4.6 為什么一切都被稱為服務 91
4.7 將事物放入文件夾以查看它們的歸屬 92
4.8 總結 .93
第5 章 高速擋和低速擋的TDD 97
5.1 我們的測試金字塔看起來怎么樣 .98
5.2 應該將領域層測試轉移到服務層嗎.98
5.3 在決定編寫哪種測試時 100
5.4 高速擋和低速擋 .101
5.5 將服務層測試與領域完全解耦 101
5.5.1 改進：在Fixture 函數(shù)中保留所有領域依存關系 .102
5.5.2 添加缺失的服務 103
5.6 將改進貫穿到E2E 測試中.104
5.7 總結 106
第6 章 工作單元模式 107
6.1 工作單元與存儲庫協(xié)作 109
6.2 通過集成測試驅動UoW . 110
6.3 工作單元及其上下文管理器 . 112
6.3.1 真正的工作單元使用SQLAlchemy 會話 . 113
6.3.2 用于測試的假工作單元 . 113
6.4 在服務層中使用工作單元（UoW） . 115
6.5 提交/ 回滾行為的顯式測試 . 116
6.6 顯式提交與隱式提交 117
6.7 示例：使用工作單元將多個操作分組到一個原子單元中 118
6.7.1 示例1：重新分配 118
6.7.2 示例2：更改批次數(shù)量 119
6.8 整理集成測試 119
6.9 總結 120
第7 章 聚合和一致性邊界 123
7.1 為什么不直接使用電子表格運行所有內容 124
7.2 不變量、約束和一致性 124
7.3 什么是聚合 126
7.4 選擇聚合.127
7.5 一個聚合= 一個存儲庫 130
7.6 關于性能.132
7.7 樂觀并發(fā)控制與版本號 133
7.8 測試我們的數(shù)據(jù)完整性規(guī)則 .137
7.8.1 使用數(shù)據(jù)庫事務隔離級別強制執(zhí)行并發(fā)規(guī)則 138
7.8.2 悲觀并發(fā)控制示例：SELECT FOR UPDATE 139
7.9 總結 140
7.10 第一部分概述 141
第二部分 事件驅動架構
第8 章 事件和消息總線 145
8.1 避免造成混亂 146
8.1.1 首先，讓我們避免弄亂我們的Web 控制器 146
8.1.2 不要弄亂我們的模型147
8.1.3 或者嘗試一下使用服務層 148
8.2 單一職責原則 149
8.3 全部都使用消息總線 149
8.3.1 模型記錄事件 .149
8.3.2 事件是簡單的數(shù)據(jù)類150
8.3.3 模型觸發(fā)事件 .150
8.3.4 消息總線將事件映射到處理程序 .152
8.4 選項1：服務層從模型中獲取事件并將其添加到消息總線 .153
8.5 選項2：服務層自己觸發(fā)事件 .154
8.6 選項3：工作單元將事件發(fā)布到消息總線 155
8.7 總結 159
第9 章 深入探討消息總線 163
9.1 新的需求引導我們走向新的架構 164
9.2 將服務層方法重構為消息處理程序167
9.2.1 消息總線現(xiàn)在從工作單元（UoW）收集事件 169
9.2.2 我們所有的測試也是根據(jù)事件編寫的 171
9.2.3 丑陋的處理方法：消息總線必須返回結果 .172
9.2.4 修改API 以處理事件 .172
9.3 實現(xiàn)我們的新需求 .173
9.4 測試驅動新的處理程序 174
9.4.1 實現(xiàn) .175
9.4.2 領域模型的新方法 177
9.5 選讀：使用模擬消息總線對事件處理程序進行單元測試 .178
9.6 總結 181
9.6.1 我們實現(xiàn)了什么 181
9.6.2 我們?yōu)槭裁催@么實現(xiàn)181
第10 章 命令與命令處理程序 183
10.1 命令與事件 .183
10.2 異常處理的差異 185
10.3 討論：事件，命令，以及錯誤處理 187
10.4 同步錯誤恢復 190
10.5 總結 192
第11 章 事件驅動架構：使用事件集成微服務 195
11.1 分布式泥球和名詞思維 196
11.2 分布式系統(tǒng)中的錯誤處理 199
11.3 替代方案：使用異步消息進行時間解耦 .200
11.4 使用Redis 發(fā)布/ 訂閱通道進行集成 201
11.5 使用端到端測試進行全面測試驅動 202
11.5.1 Redis 是另一個圍繞消息總線的輕量適配器 204
11.5.2 新發(fā)出的事件 205
11.6 內部事件與外部事件 .206
11.7 總結 206
第12 章 命令?C 查詢責任分離 209
12.1 領域模型用于寫 210
12.2 大部分用戶不會買你的家具 211
12.3 Post/Redirect/Get 和CQS 213
12.4 抓緊你的午餐，朋友們 215
12.5 測試CQRS 視圖 216
12.6 “顯而易見”的替代方案1：使用現(xiàn)有存儲庫 217
12.7 領域模型未針對讀取操作進行優(yōu)化 218
12.8 “顯而易見”的替代方案2：使用ORM 219
12.9 SELECT N 1 和其他性能考量 .219
12.10 是時候完全隨波逐流了 .220
12.11 更改讀取模型的實現(xiàn)很容易 224
12.12 總結 .225
第13 章 依賴注入和Bootstrapping 227
13.1 隱式依賴與顯式依賴 .229
13.2 顯式依賴不是很奇怪和Java 式嗎 230
13.3 準備處理程序：帶有閉包和部分函數(shù)的手動DI .233
13.4 使用類的備選方案 234
13.5 Bootstrap 腳本 235
13.6 消息總線在運行時提供處理程序 238
13.7 在程序入口使用Bootstrap 240
13.8 在測試中初始化DI 241
13.9 “正確”構建適配器：一個可用示例 243
13.9.1 定義抽象和具體實現(xiàn) 243
13.9.2 為你的測試完成一個假的版本 244
13.9.3 找出如何集成測試真實事物的方法 .245
13.10 總結 .247
后記 . 249
附錄A 圖表和表格匯總 267
附錄B 項目結構模板 269
附錄C 交換基礎設施：全部使用CSV 279
附錄D 存儲庫和工作單元Django 模式 . 285
附錄E 驗證 295