CQRS之旅——旅程2(分解领域)

旅程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编写的论文提交和会议事件调度。

在这个版本中没有实现候选清单功能，可是社区成员正在开发这个特性和其余特性。任何带外发布和更新都将在“CQRS之旅”网站上公布。

Contoso会议管理系统的上下文映射

图1和后面的列表显示上下文映射，该映射显示构成完整系统的不一样限界上下文之间的关系，所以它提供了系统如何组合在一块儿的高级概述。尽管这个上下文映射看起来很是简单，可是这些限界上下文的实现，以及更重要的是它们之间的交互，都是相对复杂的。这使咱们可以遭遇并处理CQRS模式和Event Sourcing的普遍问题，并有了一个丰富的源头来获取不少宝贵的经验和教训。

Gary(CQRS专家)发言：
关于CQRS项目的一个常见说法是：很难理解全部部分是如何组合在一块儿的，特别是若是系统中有不少命令和事件。一般，您能够对代码执行一些静态分析，以肯定事件和命令是在哪里被处理的，可是很难查明它们是在哪里发起的。在高层次上，上下文映射能够帮助您理解不一样限界上下文和相关事件之间的集成。维护有关命令和事件的最新文档能够提供更详细的信息。另外,若是你有测试,使用命令做为输入，而后检查事件，您能够经过测试来了解某个特定命令的预期结果(参见第4章“扩展和提升订单和注册限界上下文”中的测试示例)。

图1显示了构成Contoso会议管理系统的三个限界上下文。图中的箭头表示它们之间的事件数据流。

图1

下面的列表提供了关于图1中的箭头的更多信息。您能够在讨论单独限界上下文的章节中找到更多的细节。

• 在建立、更新或发布会议时报告的事件。建立或更新座位类型时报告的事件。
• 建立或更新订单时报告的事件。当与会者被分配到座位时报告的事件。
• 要求付款。
• 确认付款的成功或失败。

Gary(CQRS专家)发言：
会议管理限界上下文引起的一些事件是粗粒度的，包含多个字段。请记住，会议管理是一个使用建立、读取、更新和删除(CRUD)模式的限界上下文，不会引起细粒度的领域事件。有关更多信息，请参见第5章：“准备发布V1版本”。

为何选择这些限界上下文?

在旅程(开发)的规划(初期)阶段，很明显，这些是领域中的天然划分，能够包含各自独立的领域模型。其中一些划分比其余的更容易识别。例如，很明显，会议管理限界上下文独立于领域的其余部分。它具备与定义会议和座位类型相关的明肯定义的职责，以及与应用程序其余部分的明肯定义的集成点。

另外一方面，咱们花了一些时间才意识到订单和注册限界上下文与支付限界上下文是分开的。例如，直到应用程序的V2发行版，当OrderPaymentConfirmed事件成为OrderConfirmed事件时，与支付相关的全部概念才从订单和注册上下文中消失。

Gary(CQRS专家)发言：
随着咱们对领域模型理解的加深，咱们在整个过程当中不断细化领域模型。

更实际，从旅途的角度来看，咱们想要一组限界上下文，使咱们可以发布一个可工做的应用程序并包含一些核心的功能，它可使咱们去探索许多不一样的实现模式:CQRS, CQRS/ES,以及与传统的集成，例如CRUD风格的限界上下文。

Beth(业务经理)发言： Contoso但愿尽快发布一个可用的应用程序，可是还要可以在开发过程当中添加计划的特性和客户要求的特性，而且不须要停机就能进行升级。