CQRS与事件源实战:微软云会议管理系统深度解析

需积分: 9 22 下载量 108 浏览量 更新于2024-09-09 收藏 51B TXT 举报
《探索CQRS和事件源:微软云下的会议管理系统》是一本深入解析领域驱动设计(DDD)实践的指南,特别是在使用CQRS(Command Query Responsibility Segregation,命令查询分离)和事件源模式的背景下。本书针对Contoso公司的会议管理系统,从第1章的系统背景介绍开始,逐步深入到各个有界上下文的设计和实现。 第1章首先概述了Contoso公司及其会议管理系统,明确了系统概览和非功能性需求,如系统应具备的性能和可扩展性。接下来的章节聚焦于领域分解,将会议管理系统划分为不同的有界上下文,如订单和注册、会议管理、支付等,每个上下文都有其特定的关注点和职责。 在订单和注册有界上下文中,作者详细解释了CQRS的概念,包括领域定义、需求分析和系统架构。这部分强调了验证、事务边界、并发处理以及Aggregates和Aggregate Roots的角色。实现部分涉及使用Windows Azure服务总线进行通信,并讨论了测试的影响,如何确保系统的可靠性和健壮性。 随着系统的扩展,第4章探讨了如何修改有界上下文以支持更多的功能,如记录定位器、读者端查询和部分履行订单。这些改进涉及到CQRS命令验证和使用倒计时定时器来优化用户体验。章节最后还分享了开发者在代码理解和测试中的学习过程。 第5章转向V1发布版的准备,介绍了事件源的概念,以及如何构建基于任务的用户界面,确保跨有界上下文的集成和分布式事务。这一阶段还讨论了自治与集权、最终一致性和实现细节,包括事件存储机制和用户界面的优化。 系统版本控制在第6章中占据重要位置,包括事件定义的修改、确保消息一致性、排序和迁移策略,这些都是为了适应不断变化的需求。章节中还强调了测试的重要性,尤其是在迁移过程中发现和修复错误。 第7章着重于系统的弹性与性能优化,通过弹性处理、性能改进和无停机迁移来提升系统的稳定性和响应速度。作者详细介绍了各种技术和模式,如异步处理、快照和多主题队列。 尾声部分总结了整个项目的经验教训,包括性能优化的重要性、CQRS的适用场景、事件源的优势,以及对未来改进的反思,如更好的消息基础设施、更系统化的设计方法等。 通过这本书,读者可以了解到CQRS和事件源在实际企业级应用中的具体实践,以及在微软云环境下如何应对挑战和优化系统设计。
2015-02-12 上传
目錄 第1章 我們的領域: 會議管理系統1 1.1 Contoso公司簡介1 1.2 誰與我們同行2 1.3 Contoso會議管理系統3 1.3.1 系統概覽3 1.3.2 非功能性需求4 1.4 開始我們的旅程5 1.5 更多信息5 第2章 領域分解——站點規劃6 2.1 本章術語定義6 2.2 會議管理系統裡面的有界上下文7 2.2.1 訂單和註冊有界上下文7 2.2.2 會議管理有界上下文7 2.2.3 支付有界上下文8 2.2.4 不包括在內的有界上下文8 2.2.5 Contoso會議管理系統的上下文路線圖9 2.3 為什麼選擇這些有界上下文10 2.4 更多信息11 第3章 訂單和註冊有界上下文12 3.1 訂單和註冊有界上下文簡介12 3.2 本章術語定義13 3.3 領域定義(普適語言)14 3.4 訂單創建的需求分析16 3.5 系統架構17探索CQRS和事件源目錄3.6模式和概念17 3.6.1 系統驗證21 3.6.2 交易邊界22 3.6.3 併發處理22 3.6.4 Aggregates和Aggregate Roots22 3.7 實現細節23 3.7.1 高層架構23 3.7.2 寫者模型28 3.7.3 使用Windows Azure服務匯流排37 3.8 對測試的影響44 3.9 本章小結47 3.10 更多信息47 第4章 擴展和改進訂單和註冊有界上下文48 4.1 修改有界上下文48 4.1.1 本章術語定義49 4.1.2 用戶需求49 4.1.3 系統架構49 4.2 模式和概念51 4.2.1 記錄定位器51 4.2.2 讀者端查詢51 4.2.3 向讀者端提供部分履行的訂單信息54 4.2.4 CQRS命令驗證55 4.2.5 倒計時定時器和讀者模型56 4.3 實現細節56 4.3.1 訂單訪問碼(記錄定位器)57 4.3.2 倒計時定時器58 4.3.3 使用ASP.NET MVC驗證60 4.3.4 將改動推送到讀者端62 4.3.5 重構SeatsAvailability aggregate66 4.4 對測試的影響68 4.4.1 接受測試和領域專家68 4.4.2 使用SpecFlow功能來定義接受測試68 4.4.3 通過測試來幫助開發人員理解消息流75 4.5 代碼理解的旅程: 痛苦、釋放和學習的故事77 4.5.1 測試很重要77 4.5.2 領域測試78 4.5.3 硬幣的另外一面80 4.6 本章小結83 4.7 更多信息84 第5章 準備V1發布85 5.1 Contoso會議管理系統的V1發布版85 5.1.1 本章術語定義85 5.1.2 用戶需求86 5.1.3 系統架構87 5.2 模式和概念91 5.2.1 事件源91 5.2.2 基於任務的用戶界面92 5.2.3 有界上下文之間的集成95 5.2.4 分散式交易和事件源98 5.2.5 自治與集權99 5.2.6 讀者端的實現方法100 5.2.7 最終一致性100 5.3 實現細節101 5.3.1 會議管理有界上下文101 5.3.2 支付有界上下文102 5.3.3 事件源105 5.3.4 基於Windows Azure表格的事件庫111 5.3.5 訂單總價計算114 5.4 對測試的影響114 5.4.1 時序問題114 5.4.2 引入領域專家115 5.5 本章小結115 5.6 更多信息115 第6章 系統版本控制116 6.1 本章術語定義116 6.1.1 用戶需求116 6.1.2 系統架構117 6.2 模式和概念118 6.2.1 修改事件定義118 6.2.2 確保消息的自洽性119 6.2.3 集成事件的保存121 6.2.4 消息排序122 6.3 實現細節123 6.3.1 對零成本訂單的支持123 6.3.2 顯示剩餘座位數127 6.3.3 刪除重複命令130 6.3.4 確保消息排序131 6.3.5 保存會議管理有界上下文的事件135 6.3.6 從V1版本遷移到V2版本139 6.4 對測試的影響140 6.4.1 重訪SpecFlow140 6.4.2 在遷移過程中發現錯誤143 6.5 本章小結143 6.6 更多信息144 第7章 加入彈性和優化性能145 7.1 本章術語定義145 7.2 系統架構145 7.3 加入彈性147 7.3.1 增加事件重複處理時的彈性148 7.3.2 確保命令的發送148 7.4 優化性能148 7.4.1 優化前的用戶界面流程149 7.4.2 用戶界面優化150 7.4.3 基礎設施優化151 7.5 無停機遷移158 7.6 實現細節159 7.6.1 改進RegistrationProcessManager類160 7.6.2 用戶界面流程優化165 7.6.3 消息的非同步接收、處理和發送170 7.6.4 在流程內部對命令進行同步處理171 7.6.5 使用備忘錄模式來實現快照173 7.6.6 對事件進行並行發布175 7.6.7 在訂購服務裡面對消息進行過濾176 7.6.8 為SeatsAvailability aggregate創建專門的SessionSubscriptionReceiver實例177 7.6.9 緩存讀者模型數據179 7.6.10 使用多個議題來劃分服務匯流排180 7.6.11 其他的優化和強化措施181 7.7 對測試的影響184 7.7.1 集成測試185 7.7.2 用戶界面測試185 7.8 本章小結185 7.9 更多信息185 第8章 尾聲: 經驗教訓186 8.1 我們學到了什麼186 8.1.1 性能很重要186 8.1.2 實現消息驅動並不簡單187 8.1.3 雲平台的挑戰187 8.1.4 不同的CQRS188 8.1.5 事件源和交易日誌記錄190 8.1.6 引入領域專家190 8.1.7 什麼時候該使用CQRS190 8.2 如果重新來過,我們會做的有什麼不同191 8.2.1 以牢靠的消息和保存基礎設施為起點191 8.2.2 更好地利用基礎設施的能力191 8.2.3 採納更加系統化的方法來實現流程管理器192 8.2.4 對應用程序實施不同的劃分192 8.2.5 以不同方式組織項目團隊192 8.2.6 對領域和有界上下文的CQRS適用性進行評估192 8.2.7 為性能進行規劃192 8.2.8 重新考慮用戶界面193 8.2.9 探索事件源的其他用處193 8.2.10 探索有界上下文的集成問題193 8.3 更多信息194