在研究和测试解决方案时，可以在本地运行它，可以使用Azure compute emulator，也可以直接运行MVC web应用程序，并运行承载消息处理程序和领域域对象的控制台应用程序。在本地运行应用程序时，可以使用本地SQL Server Express数据库，使用在SQL Server Express数据库实现的简单的消息传递基础设施和简单事件存储。
备注：事件存储和消息传递基础设施的基于sql的实现只是为了帮助您在本地运行应用程序以进行探索和测试。它们并不是想要说明一种用于实际产品的方法。有关运行应用程序的选项的更多信息，请参见附录1“发布说明”。
会议管理有界上下文会议管理限界上下文是一个简单的两层，创建/读取/更新(CRUD)风格的web应用程序。它使用ASP.NET MVC和Entity Framework。
这个限界上下文必须与实现CQRS模式的其他限界上下文集成。
模式和概念本节介绍了在团队旅程的当前阶段，应用程序的一些关键地方，并介绍了团队在处理这些地方时遇到的一些挑战。
事件源Contoso的团队最初在没有使用事件源的情况下实现了订单和注册的限界上下文。然而，在实现过程中，很明显，使用事件源将有助于简化这个限界上下文。
在第4章“扩展和增强订单和注册边界上下文”中，团队发现我们需要使用事件将更改从写端推到读端。在读端，OrderViewModelGenerator类订阅Order聚合发布的事件，并使用这些事件更新由读取模型查询的数据库中的视图。
这已经是事件源实现的一半了，因此在整个限界上下文中使用基于事件的单一持久性机制是有意义的。
事件源基础设施可在其他限界上下文中重用，订单和注册的实现也变得更加简单。
.gif)
作为一个实际的问题，在V1发布之前，团队只有有限的时间来实现一个产品级别的事件存储。他们基于Azure表创建了一个简单的基本事件存储作为临时解决方案。但是，在将来从一个事件存储迁移到另一个事件存储时，他们可能会面临问题。
关键是演进：例如，可以展示如何实现事件源使您摆脱那些冗长的数据迁移，甚至允许您从过去构建报告。
tom Janssens - CQRS Advisors邮件列表
团队使用Azure表存储实现了基本的事件存储。如果您将应用程序托管在Azure中，还可以考虑使用Azure blobs或SQL数据库来存储事件。
在为事件存储选择基础技术时，应该确保您的选择能够提供应用程序所需的可用性、一致性、可靠性、可伸缩性和性能需要。
在选择Azure中的存储机制时要考虑的问题之一是成本。如果使用SQL数据库，则根据数据库的大小进行计费。如果使用Azure table或blob存储，则根据使用的存储量和存储事务的数量进行计费。您需要仔细评估系统中不同聚合上的使用模式，以确定哪种存储机制的成本效率最高。可能会发现，不同的存储机制对于不同的聚合类型是有意义的。您可以引入一些优化来降低成本，例如使用缓存来减少存储事务的数量。
根据我的经验，如果您正在进行新手开发，那么您需要非常好的辩论来选择一种SQL数据库。Azure存储服务应该是默认的选择。但是，如果您已经有一个想要迁移到云中的SQL Server数据库，那么情况就不同了。
mark Seemann - CQRS Advisors邮件列表
确定聚合在团队为V1版本创建的基于Azure表存储的事件存储实现中，我们使用聚合ID作为分区键。这使得定位包含任何特定聚合事件的分区非常有效。
在某些情况下，系统必须定位相关的聚合。例如，订单聚合可能具有相关的注册聚合，其中包含分配到特定座位的参会者的详细信息。在这个场景中，团队决定为相关的聚合对(订单和注册聚合)重用相同的聚合ID，以便于查找。
在这种情况下，您需要考虑是否应该有两个聚合。您可以将注册建模为订单聚合内的实体。