第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
3.6模式和概念 17
3.6.1系统验证 21
3.6.2交易边界 22
3.6.3并发处理 22
3.6.4 Aggregates和Aggregate Roots 22
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 aggregate 66
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重访SpecFlow 140
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不同的CQRS 188
8.1.5事件源和交易日志记录 190
8.1.6引入领域专家 190
8.1.7什么时候该使用CQRS 190
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