第1章 我们的领域：会议管理系统

1.1 Contoso公司简介

1.2谁与我们同行

1.3 Contoso会议管理系统

1.3.1系统概览

1.3.2非功能性需求

1.4开始我们的旅程

1.5更多信息

第2章 领域分解——站点规划

2.1本章术语定义

2.2会议管理系统里面的有界上下文

2.2.1订单和注册有界上下文

2.2.2会议管理有界上下文

2.2.3支付有界上下文

2.2.4不包括在内的有界上下文

2.2.5 Contoso会议管理系统的上下文路线图

2.3为什么选择这些有界上下文

2.4更多信息

第3章 订单和注册有界上下文

3.1订单和注册有界上下文简介

3.2本章术语定义

3.3领域定义（普适语言）

3.4订单创建的需求分析

3.5系统架构

3.6模式和概念

3.6.1系统验证

3.6.2交易边界

3.6.3并发处理

3.6.4 Aggregates和Aggregate Roots

3.7实现细节

3.7.1高层架构

3.7.2写者模型

3.7.3使用Windows Azure服务总线

3.8对测试的影响

3.9本章小结

3.10更多信息

第4章 扩展和改进订单和注册有界上下文

4.1修改有界上下文

4.1.1本章术语定义

4.1.2用户需求

4.1.3系统架构

4.2模式和概念

4.2.1记录定位器

4.2.2读者端查询

4.2.3向读者端提供部分履行的订单信息

4.2.4 CQRS命令验证

4.2.5倒计时定时器和读者模型

4.3实现细节

4.3.1订单访问码（记录定位器）

4.3.2倒计时定时器

4.3.3使用ASP.NET MVC验证

4.3.4将改动推送到读者端

4.3.5重构SeatsAvailability aggregate

4.4对测试的影响

4.4.1接受测试和领域专家

4.4.2使用SpecFlow功能来定义接受测试

4.4.3通过测试来帮助开发人员理解消息流

4.5代码理解的旅程：痛苦、释放和学习的故事

4.5.1测试很重要

4.5.2领域测试

4.5.3硬币的另外一面

4.6本章小结

4.7更多信息

第5章 准备V1发布

5.1 Contoso会议管理系统的V1发布版

5.1.1本章术语定义

5.1.2用户需求

5.1.3系统架构

5.2模式和概念

5.2.1事件源

5.2.2基于任务的用户界面

5.2.3有界上下文之间的集成

5.2.4分布式交易和事件源

5.2.5自治与集权

5.2.6读者端的实现方法

5.2.7最终一致性

5.3实现细节

5.3.1会议管理有界上下文

5.3.2支付有界上下文

5.3.3事件源

5.3.4基于Windows Azure表格的事件库

5.3.5订单总价计算

5.4对测试的影响

5.4.1时序问题

5.4.2引入领域专家

5.5本章小结

5.6更多信息

第6章 系统版本控制

6.1本章术语定义

6.1.1用户需求

6.1.2系统架构

6.2模式和概念

6.2.1修改事件定义

6.2.2确保消息的自洽性

6.2.3集成事件的保存

6.2.4消息排序

6.3实现细节

6.3.1对零成本订单的支持

6.3.2显示剩余座位数

6.3.3删除重复命令

6.3.4确保消息排序

6.3.5保存会议管理有界上下文的事件

6.3.6从V1版本迁移到V2版本

6.4对测试的影响

6.4.1重访SpecFlow

6.4.2在迁移过程中发现错误

6.5本章小结

6.6更多信息

第7章 加入弹性和优化性能

7.1本章术语定义

7.2系统架构

7.3加入弹性

7.3.1增加事件重复处理时的弹性

7.3.2确保命令的发送

7.4优化性能

7.4.1优化前的用户界面流程

7.4.2用户界面优化

7.4.3基础设施优化

7.5无停机迁移

7.6实现细节

7.6.1改进RegistrationProcessManager类

7.6.2用户界面流程优化

7.6.3消息的异步接收、处理和发送

7.6.4在流程内部对命令进行同步处理

7.6.5使用备忘录模式来实现快照

7.6.6对事件进行并行发布

7.6.7在订购服务里面对消息进行过滤

7.6.8为SeatsAvailability aggregate创建专门的SessionSubscriptionReceiver实例

7.6.9缓存读者模型数据

7.6.10使用多个议题来划分服务总线

7.6.11其他的优化和强化措施

7.7对测试的影响

7.7.1集成测试

7.7.2用户界面测试

7.8本章小结

7.9更多信息

第8章 尾声：经验教训

8.1我们学到了什么

8.1.1性能很重要

8.1.2实现消息驱动并不简单

8.1.3云平台的挑战

8.1.4不同的CQRS

8.1.5事件源和交易日志记录

8.1.6引入领域专家

8.1.7什么时候该使用CQRS

8.2如果重新来过，我们会做的有什么不同

8.2.1以牢靠的消息和保存基础设施为起点

8.2.2更好地利用基础设施的能力

8.2.3采纳更加系统化的方法来实现流程管理器

8.2.4对应用程序实施不同的划分

8.2.5以不同方式组织项目团队

8.2.6对领域和有界上下文的CQRS适用性进行评估

8.2.7为性能进行规划

8.2.8重新考虑用户界面

8.2.9探索事件源的其他用处

8.2.10探索有界上下文的集成问题

8.3更多信息