CQRS之旅——旅程1(咱们的领域：Contoso会议管理系统)

旅程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实现会议管理系统的过程。