第1章我们的领域： 会议管理系统1
1.1Contoso公司简介1
1.2谁与我们同行2
1.3Contoso会议管理系统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.5Contoso会议管理系统的上下文路线图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.4Aggregates和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.4CQRS命令验证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.1Contoso会议管理系统的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
