在这个版本中没有实现候选清单功能，但是社区成员正在开发这个特性和其他特性。任何带外发布和更新都将在“CQRS之旅”网站上公布。
Contoso会议管理系统的上下文映射图1和后面的列表显示上下文映射，该映射显示构成完整系统的不同限界上下文之间的关系，因此它提供了系统如何组合在一起的高级概述。尽管这个上下文映射看起来非常简单，但是这些限界上下文的实现，以及更重要的是它们之间的交互，都是相对复杂的。这使我们能够遭遇并处理CQRS模式和Event Sourcing的广泛问题，并有了一个丰富的源头来获取很多宝贵的经验和教训。
Gary(CQRS专家)发言：
关于CQRS项目的一个常见说法是：很难理解所有部分是如何组合在一起的，特别是如果系统中有很多命令和事件。通常，您可以对代码执行一些静态分析，以确定事件和命令是在哪里被处理的，但是很难查明它们是在哪里发起的。在高层次上，上下文映射可以帮助您理解不同限界上下文和相关事件之间的集成。维护有关命令和事件的最新文档可以提供更详细的信息。另外,如果你有测试,使用命令作为输入，然后检查事件，您可以通过测试来了解某个特定命令的预期结果(参见第4章“扩展和提高订单和注册限界上下文”中的测试示例)。
图1显示了构成Contoso会议管理系统的三个限界上下文。图中的箭头表示它们之间的事件数据流。
下面的列表提供了关于图1中的箭头的更多信息。您可以在讨论单独限界上下文的章节中找到更多的细节。
在创建、更新或发布会议时报告的事件。创建或更新座位类型时报告的事件。
创建或更新订单时报告的事件。当与会者被分配到座位时报告的事件。
要求付款。
确认付款的成功或失败。
Gary(CQRS专家)发言：
会议管理限界上下文引发的一些事件是粗粒度的，包含多个字段。请记住，会议管理是一个使用创建、读取、更新和删除(CRUD)模式的限界上下文，不会引发细粒度的领域事件。有关更多信息，请参见第5章：“准备发布V1版本”。
在旅程(开发)的规划(初期)阶段，很明显，这些是领域中的自然划分，可以包含各自独立的领域模型。其中一些划分比其他的更容易识别。例如，很明显，会议管理限界上下文独立于领域的其他部分。它具有与定义会议和座位类型相关的明确定义的职责，以及与应用程序其他部分的明确定义的集成点。
另一方面，我们花了一些时间才意识到订单和注册限界上下文与支付限界上下文是分开的。例如，直到应用程序的V2发行版，当OrderPaymentConfirmed事件成为OrderConfirmed事件时，与支付相关的所有概念才从订单和注册上下文中消失。
Gary(CQRS专家)发言：
随着我们对领域模型理解的加深，我们在整个过程中不断细化领域模型。
更实际，从旅途的角度来看，我们想要一组限界上下文，使我们能够发布一个可工作的应用程序并包含一些核心的功能，它可以使我们去探索许多不同的实现模式:CQRS, CQRS/ES,以及与传统的集成，例如CRUD风格的限界上下文。
Beth(业务经理)发言：
Contoso希望尽快发布一个可用的应用程序，但是还要能够在开发过程中添加计划的特性和客户要求的特性，并且不需要停机就能进行升级。