旅程5：准备发布V1版本 添加功能和重构，为V1版本发布做准备。 “大多数人在完成一件事之后，就像留声机的唱片一样，一遍又一遍地使用它，直到它破碎，忘记了过去是用来创造更多未来的东西。” -- 弗雷娅.斯塔克 发布Contoso会议管理系统V1版本：
本章描述了团队为准备Contoso会议管理系统的第一个产品版本所做的更改。这项工作包括对前两章介绍的订单(Order)和注册(Registrations)限界上下文的一些重构和功能添加，以及一个新的会议管理(Conference Management)限界上下文和一个新的支付(Payment)限界上下文。
团队在此过程中进行的一个关键重构是将事件源(ES)引入订单(Order)和注册(Registrations)限界上下文中。
实现CQRS模式的一个预期好处是，它将帮助我们在复杂系统中管理变化。在CQRS旅程中发布一个V1版本将帮助团队评估当我们从V1版本迁移到系统的下一个产品版本时使用CQRS和ES的好处。剩下的章节将描述V1版本发布后的情况。
本章描述了团队在此阶段添加到公共网站的用户界面(UI)，并包括了对基于任务的UI的讨论。
本章的工作术语定义：本章使用了一些术语，我们将在下面进行描述。有关更多细节和可能的替代定义，请参阅参考指南中的“深入CQRS和ES”。
Access code(访问代码)：当业务客户创建一个新的会议时，系统生成一个5个字符的访问代码并通过电子邮件发送给业务客户。业务客户可以使用其电子邮件地址和会议管理网站上的访问代码在稍后的日子从系统中检索会议详细信息。该系统使用访问码而不是密码，因此业务客户不需要仅为了创建一个支付而注册账户。
Event sourcing(事件源)：事件源是在系统中持久化和重新加载聚合状态的一种方法。每当聚合的状态发生更改时，聚合将引发详细说明状态更改的事件。然后，系统将此事件保存到事件存储中。系统可以通过重播与聚合实例关联的所有先前保存的事件来重新创建聚合的状态。事件存储成为系统存储数据的记录簿。此外，您还可以使用事件源作为审计数据的来源，作为查询历史状态、从过去的数据获得新的业务见解以及重播事件以进行调试和问题分析的方法。
Eventual consistency(最终一致性)：最终一致性是一个一致性模型，它不能保证立即访问更新的值。对数据对象进行更新后，存储系统不保证对该对象的后续访问将返回更新后的值。然而，存储系统确实保证，如果在足够长的时间内没有对对象进行新的更新，那么最终所有访问都可以返回最后更新的值。
用户故事(User stories)在这个过程的这个阶段，团队实现了下面描述的用户故事。
定义通用语言业务客户：业务客户代表使用会议管理系统运行其会议的组织。
座位：座位代表会议上的一个空间或进入会议上特定会议如欢迎招待会、教程或研讨会的通道。
注册者：注册者是与系统交互下订单并为这些订单付款的人。注册者还创建与订单关联的注册。
会议管理限界界的上下文的用户故事业务客户可以创建新的会议并管理它们。在业务客户创建新会议之后，他可以使用电子邮件地址和会议定位器访问代码访问会议的详细信息。当业务客户创建会议时，系统生成访问代码。
业务客户可以指定以下关于会议的信息:
名称、描述和Slug(用于访问会议的URL的一部分)。
会议的开始和结束日期。
会议提供的不同座位类型和配额。
此外，业务客户可以通过发布或取消发布会议来控制会议在公共网站上的可见性。
业务客户可以使用会议管理网站查看订单和与会者列表。
订单和注册限界的上下文的用户故事当注册者创建一个订单时，可能无法完全完成该订单。例如，注册者申请5个座位参加整个会议，5个座位参加欢迎招待会，3个座位参加会前讲习班。整个会议可能只有3个座位，欢迎招待会只有1个座位，但会前讲习班有3个以上的座位。系统会将此信息显示给注册者，并让她有机会在继续付款过程之前按顺序调整每种座位的数量。
当注册者选择了每种座位类型的数量后，系统会计算订单的总价，然后注册者可以使用在线支付服务支付这些座位。Contoso不代表客户处理付款。每个业务客户必须有一个通过在线支付服务接受支付的机制。在项目的后期，Contoso将添加对业务客户的支持，以将他们的发票系统与会议管理系统集成在一起。在将来的某个时候，Contoso可能会提供一项代表客户收款的服务。
备注：在系统的这个版本中，实际上支付系统是模拟的。
注册者在会议上购买了座位后，可以为参会者分配这些座位。系统存储每个参会者的姓名和联系方式。
架构