旅程2：分解领域 设计停靠站点 “没有石头就没有拱门” --马可波罗
在本章中，我们将对Contoso会议管理系统进行一个高层次的概述。这将帮助您理解应用程序的结构、集成点以及应用程序的各个部分之间的关系。
在这里，我们借用Eric Evans在他的书《领域驱动设计 软件核心复杂性应对之道(Addison-Wesley Professional, 2003)中描述的领域驱动设计(DDD)方法来描述这个高级结构。DDD是成功实现CQRS模式的先决条件虽然还没有达成普遍的共识，但我们团队依然决定按照CQRS社区的惯例使用DDD里众多概念和方法，例如领域、限界上下文,和聚合。参考指南的第1章“上下文中的CQRS”更详细地讨论了DDD和CQRS模式之间的关系。
本章使用的定义在本章中，我们使用了一些术语，我们将在稍后定义它们。有关更多细节和可能的替代定义，请参见参考指南中的第1章“上下文中的CQRS”。
领域(Domain):领域是指Contoso会议管理系统的业务域(参考实现)。第一章“我们的领域：Contoso会议管理系统”概述了这个领域。
限界上下文(Bounded Context):术语限界上下文来自Eric Evans的书。简而言之，Evans引入这个概念是为了将一个大型的、复杂的系统分解成更易于管理的部分。大型系统由多个限界上下文组成。每个限界上下文都是自己包含领域模型的上下文，并且有它自己的通用语言(Ubiquitous Language)。您还可以将限界上下文看做明确定义了一致性边界的自主业务组件。一个限界上下文通常通过引发事件(Raising Events)与另一个限界上下文通信。
Gary(CQRS专家)发言：
当你使用CQRS模式时，经常使用事件在限界上下文中进行通信。集成还有其他方法，比如在数据库级共享数据。
上下文映射:根据Eric Evans的说法，您应该“描述模型之间的联系点，明确所有通信需要的转换，并突出任何共享的内容。”这个练习产生了所谓的上下文映射，它有几个用途，包括提供整个系统的概览，以及帮助人们理解不同的限界上下文如何相互交互的细节。
会议系统中的限界上下文
订单和注册限界上下文：在订单和注册限界上下文中包含预订、付款和注册项。当注册用户与系统交互时，系统创建一个订单来管理预订、付款和注册。订单包含一个或多个订单项。
预订是在会议上临时预订一个或多个座位。当注册用户开始订购会议上的一些座位时，系统会为这些座位创建预订。然后，其他用户无法预订这些座位。预订保留15分钟，在此期间，登录人可以通过支付座位的费用完成订购过程。如果用户没有在15分钟内付款，系统将删除该预订，其他用户可以继续预订这些座位。
Carlos(领域专家)发言：
我们讨论过将系统保留预订的时间期限设置成一个参数，这样客户可以为每次会议调整这个预留时间。如果我们确定需要这种级别的控制，那么这可能是我们需要添加的一个特性。
会议管理限界上下文：在这个限界上下文中，业务客户可以创建新的会议并管理它们。在业务客户创建新会议之后，他可以使用电子邮件和访问代码来访问查看会议的详细信息。当业务客户创建会议时，系统生成访问代码。
业务客户可以指定以下关于会议的信息:
名称、描述和slug(用于访问会议的URL的一部分)。
会议的开始和结束日期。
会议提供的不同座位类型和配额。
此外，业务客户可以通过发布或取消发布来控制会议在公共网站上的可见性。
业务客户还可以使用会议管理网站查看订单和参会者列表。
支付限界上下文：支付限界上下文负责管理会议管理系统和外部支付系统之间的交互。它将必要的付款信息转发给外部系统，并接收付款被接受或拒绝的结果。它将支付的成功或失败报告给会议管理系统。一开始，支付限界上下文将假定业务客户在第三方支付系统中有一个帐户(尽管不一定是商家帐户)，或者业务客户将接受发票支付。
旅程中未包含的几个限界上下文虽然这几个限界上下文没有进入Contoso会议管理系统的最终版本，但是做了一些工作。社区成员正在开发这些以及一些其他功能，任何带外发布和更新都将在“CQRS之旅”网站上公布。如果您想对这些限界上下文或系统的任何其他方面有所贡献，请访问项目“CQRS Journey”网站或通过cqrsjourney@microsoft.com让我们知道。
折扣限界上下文: 处理会议座位的购买管理和应用折扣。该会议与主系统三个已存在的限界上下文集成在一起。
偶尔断开连接的会议管理客户端：这个限界上下文用于处理会议现场的管理，具有处理标签打印、记录参会者到达情况和额外座位销售的功能。
提交和进度管理限界上下文：用于处理使用Node.js编写的论文提交和会议事件调度。