Jana(软件架构师)发言：
从本质上讲，我们所依赖的事实是，预订会成功，所以避免了耗时的检查。但我们仍然要在注册人付款之前执行检查，以确保座位是可用的。
但是，如果控制器在发送RegisterToConference命令之前就检查并发现没有足够的座位来完成订单，则可以重新显示注册屏幕，使注册者能够根据当前可用性更新其订单。
Jana(软件架构师)发言：
对这一战略的一个可能改进是，在发送RegisterToConference命令之前，看看是否可能有足够的座位可用。这可以减少注册者在最后几个座位售罄时调整订单的次数。然而，这种场景发生的频率很低，可能不值得实现。
在V2版本中，MVC控制器不显示付款页面，直到领域发布OrderTotalsCalculated事件，并且系统更新了price-order视图模型。此事件是控制器显示屏幕之前发生的最后一个事件。
如果系统更早地计算总数并更新价格订单视图模型，控制器就可以更早地显示付款页面。团队确定，订单聚合可以在订单下单时计算总数，而不是在预订完成时计算总数。这将使UI流比V2版本更快的走到付款页面。
优化基础设施“每天都有一些新的事实浮现，一些新的障碍那些威胁着我们的最严重的障碍。我想这就是为什么这款游戏如此值得一玩的原因。” 罗伯特·弗尔肯·斯科特
团队在旅程的这个阶段添加的第二组优化与系统的基础设施相关。这些更改同时处理了系统的性能和可伸缩性。下面的部分描述了我们在这里所做的最重要的更改。
异步发送和接收命令和事件作为优化过程的一部分，团队更新了系统，以确保在服务总线上发送的所有消息都是异步发送的。这种优化旨在提高应用程序的总体响应能力，并提高消息的吞吐量。作为此更改的一部分，团队还使用了Transient Fault Handling Application Block来处理使用服务总线时遇到的任何瞬时错误。
Markus(软件开发人员)发言：
这种优化导致了对基础设施代码的重大更改。将异步调用与Transient Fault Handling Application Block相结合是复杂的，我们将受益于c# 4.5中的一些新的简化语法!
Jana(软件架构师)发言：
有关在使用Azure服务总线时帮助优化性能的其他经过验证的实践，请参阅本指南：Best Practices for Performance Improvements Using Service Bus Brokered Messaging
V2版本对命令和事件使用相同的消息传递基础设施——Azure服务总线。团队评估了Contoso会议管理系统是否需要使用相同的基础设施发送所有命令消息。
在决定是否继续使用Azure服务总线传输所有命令消息时，我们考虑了许多因素。
哪些命令(如果有的话)可以在进程中处理?
如果处理一些进程中的命令，系统的弹性会降低吗?
如果在进程中处理一些命令，会有显著的性能提升吗?
我们确定了一组命令，系统可以从会议web应用程序在进程中同步地发送这些命令。为了实现这种优化，我们必须向会议web应用程序添加一些基础设施元素(事件存储库、事件总线和事件发布者)。以前，这些基础设施元素只在系统的工作角色中。
异步命令是不存在的，它实际上是另一个事件。如果我必须接受一个你发给我的消息并且如果我不同意必须发出一个事件。那这就不是你要我做什么，而是你告诉我什么已经做完了。乍一看，这似乎只有一点点不同，但它有很多含义。
Why do lots of developers use one-way command messaging (async handling) when it's not needed? Greg Young - DDD/CQRS Group
对事件源使用快照性能测试还发现了使用可用座位(SeatsAvailability)聚合的瓶颈，我们使用快照的形式解决了这个瓶颈。
Jana(软件架构师)发言：
一旦团队确定了这个瓶颈，就很容易实现和测试这个解决方案。我们在实现CQRS模式时所遵循的方法的优点之一是：我们可以在系统中进行小的局部更改。更新不需要我们去跨系统的多个部分进行复杂的更改。