旅程1：我们的领域：Contoso会议管理系统
起点:我们从哪里来，我们带来了什么，谁将与我们同行?“
只要前进，我愿意去任何地方。” --大卫•利文斯通
本章介绍了一个虚构的公司Contoso。它描述了Contoso计划推出的会议管理系统，这是一个新的在线服务，可以使其他公司或个人通过此系统组织和管理自己的会议和活动。本章从高层次描述了新系统的一些功能和非功能需求，以及为什么Contoso希望使用CQRS和Event Sourcing实现部分功能。与任何考虑此过程的公司一样，有许多问题需要思考和挑战，特别是这是Contoso第一次同时使用CQRS和Event Sourcing。接下来的章节将逐步展示Contoso是如何设计和构建其会议管理系统的。
另外，本章还介绍了一个虚构的专家小组来评论开发工作。
Contoso公司
Contoso是一家新兴的ISV公司，拥有大约20名员工，专门使用微软技术开发解决方案。Contoso的开发人员熟悉各种微软产品和技术，包括.Net Framework、ASP.NET MVC和Microsoft Azure。一些开发人员以前有使用领域驱动设计(DDD)方法的经验，但是他们以前都没有使用过CQRS模式。
会议管理系统应用程序是Contoso想要推向市场的首批创新在线服务之一。作为一家初创企业，Contoso希望用最少的硬件和IT人员投资来开发和推出这些服务。为了开始扩大市场份额，Contoso想要快速进入市场，但是没有时间实现第一个版本中所有计划的功能。所以，重要的是，它采用的体系结构要能够轻松地适应更改和增强，同时对系统的现有用户的影响最小。Contoso选择将应用程序部署在Azure上，以利用其随需求增长而扩展应用程序的能力。
这次CQRS之旅谁将和我们同行
如前所述，本指南和随附的参考实现里描述了这次CQRS之旅。一个专家小组将在我们进行的过程中对我们的开发工作发表意见。其中包括CQRS专家、软件架构师、开发人员、领域专家、IT专家和业务经理。他们都会从自己的角度进行评论。
| 人物 | 角色描述 |
|---|---|
 |
Gary是一位CQRS专家。他确保基于CQRS的解决方案可以为公司工作，并提供切实的好处。他是一个谨慎的人，理由很充分。 ”定义CQRS模式很简单。实现CQRS模式所能带来的好处并不总是那么简单。“ |
 |
Jana是一名软件架构师。她设计应用程序的总体结构。她的观点既切合实际又具有战略意义。换句话说，她不仅考虑现在需要什么技术方法，还考虑公司未来需要什么方向。Jana从事过使用DDD的项目。 “平衡公司、用户、It组织、开发人员和我们所依赖的技术平台的需求并不容易。” |
 |
Markus是一个软件开发人员，他是CQRS模式的新手。他善于分析，注重细节，做事有条不紊。他专注于手头的任务，即构建一个出色的应用程序。他知道他是最终对代码负责的人。 “我不关心您想为应用程序使用什么架构，我都能完成它” |
 |
Carlos是领域专家。他通晓会议管理的所有细节。他在许多帮助人们举办会议的组织中工作过。他还担任过许多不同的职务：销售、市场营销、会议管理和顾问。 “我想确保团队了解这项业务的运作方式，以便我们能够提供世界级的在线会议管理系统。” |
 |
Poe是一名专业IT人员，在云计算中部署和运行应用程序方面是专家。他对实际解决方案有着浓厚的兴趣，毕竟，他是那个在凌晨3点有问题的时候就会被呼叫的人。 “在云中运行复杂的应用程序所面临的挑战和管理本地应用程序所面临的挑战不同。我想确保我们新的会议管理系统符合我们发布的服务水平协议(service-level agreements, SLA)。” |
 |
Beth是一位业务经理。她帮助公司规划他们的业务将如何发展。她了解公司所处的市场，公司拥有的资源，以及公司的目标。她既有战略眼光，又对公司的日常运营感兴趣。 ”公司在资源方面面临着许多相互矛盾的需求。我想确保我们的公司能平衡这些需求，并采取一项能让我们在中长期取得成功的商业计划。“ |
如果您对某一特定领域感兴趣，可以查看与您兴趣一致的专家提供的注释。
Contoso会议管理系统
本节将按照团队在旅程开始时的设定，介绍Contoso会议管理系统。该团队以前从未使用过CQRS模式，因此，我们在旅程结束时交付的系统可能并不完全符合这一描述，因为:
- 我们边学边做的东西可能会影响我们最终的交付。
- 这是一个学习的过程，很难估计我们能在可用的时间内完成什么。
系统概述
Contoso计划建立一个在线会议管理系统，使其客户能够计划和管理在物理位置举行的会议。该系统将使Contoso的客户能够:
- 管理会议不同类型座位的销售。
- 创建一个会议并定义该会议的特征。
Contoso会议管理系统将是一个多租户、云托管的应用程序。业务客户在创建和管理会议之前需要在系统中注册。
会议售座
业务客户定义会议可用的座位数量。业务客户还可以指定会议上的活动，如研讨会、招待会和高级会议，与会者必须有单独的票。业务客户还定义了这些活动可用的座位数量。
该系统管理座位的销售，以确保会议和子活动没有超额认购。该系统的这部分还将执行候补名单，以便如果其他与会者取消，他们的座位可以重新分配。
系统将要求与会者的姓名与购买的座位相关联，以便现场系统在与会者到达会议现场时为他们打印徽章。
创建会议
业务客户可以创建新的会议，并管理有关会议的信息，如会议名称、描述和日期。业务客户还可以通过发布会议，使会议在Contoso会议管理系统网站上可见，或者通过取消发布来隐藏会议。
此外，业务客户还可以为会议定义每种座位的类型和可用数量。
Contoso还计划可以使业务客户能够指定会议的以下特征:
- 论文提交过程是否需要审阅。
- 什么样的收费架构。
- 关键人员是哪位，例如：项目主席，活动策划者
非功能性需求
Contoso对其会议管理系统有两个主要的非功能性需求：可扩展性和灵活性，它希望CQRS模式能够帮助它满足这两个需求。
可扩展性
会议管理系统将托管在云端。Contoso选择云平台的原因之一是它的可扩展性和弹性潜力。
尽管像Azure这样的云平台允许您通过添加(或删除)角色实例来扩展应用程序，但是您仍然必须将应用程序设计为可扩展的。对于许多应用程序来说，读操作的数量远远超过写操作的数量。通过将应用程序的读写操作划分为单独的对象，CQRS模式允许Contoso将这些操作划分为单独的Azure角色，这些角色可以彼此独立扩展。这意味着Contoso有机会更有效地扩展会议管理系统，并更好地利用它所使用的Azure角色实例。
灵活性
Contoso会议管理系统所处的市场竞争非常激烈，而且发展非常迅速。为了竞争，Contoso必须能够快速有效地使会议管理系统适应市场的变化。对灵活性的这一要求可分为若干相关方面:
-
系统必须能够不断改进，以满足新的需求，并对市场的变化做出反应。
Beth(业务经理)发言：
Contoso计划通过快速响应市场变化和客户需求来竞争。Contoso必须能够快速而无痛地改进扩展这个系统。 -
系统必须能够同时运行多个版本的软件，以支持正在使用来开会的客户，以及不希望立即升级到新版本的客户。其他客户可能希望在软件的新版本可用时将现有会议数据迁徙到新版本。
Poe(IT运维)发言：
这是一个巨大的挑战：在所有客户还在运行系统的过程中进行不停机升级。 -
Contoso希望这款软件至少能使用五年。它必须能够适应这段时期内的重大变化。
-
Contoso不希望系统某些部分的复杂性成为未来改变的障碍。
-
Contoso希望使用不同层次的开发人来开发系统的不同部分，简单的任务使用便宜的开发人员，更贵和更有经验的的开发人员用于开发系统的关键部分。
Gary(CQRS专家)发言：
在CQRS社区中有一些争论，关于在实践中，您是否可以为CQRS模式实现的不同部分使用不同的开发团队。
即将开始CQRS之旅
下一章是我们CQRS旅程的开始。它提供了关于Contoso会议管理系统的更多信息，并描述了系统的一些高级部分。随后的章节描述了Contoso实现会议管理系统的过程。
