Gary(CQRS专家)发言：
单个进程(部署中的角色实例)可以承载多个限界上下文。在此场景中，您不需要为限界上下文使用服务总线来彼此通信。
实现CQRS模式比实现传统的(创建、读取、更新、删除)CRUD风格的系统更复杂。对于这个项目，第一次学习CQRS和创建分布式、异步消息传递基础设施的开销也很大。我们在此过程中的经验清楚地向我们证实了为什么CQRS模式不是顶级体系结构。您必须确保实现基于CQRS的限界上下文相关的成本是值得的，通常，您将在高竞争、高协作的领域中看到CQRS模式的好处。
Gary(CQRS专家)发言：
分析业务需求、构建有用的模型、维护模型、用代码表示它以及使用CQRS模式实现它都需要时间和金钱。如果这是您第一次实现CQRS模式，那么您还需要对基础设施元素(如消息总线和事件存储)进行开销投资。
对于事件源和事务日志是否等同于同一件事，我们进行了一些讨论：它们都创建了所发生事情的记录，并且都允许您通过重播历史数据来重新创建系统的状态。结论是，事件的显著特征是除了记录所发生的事实之外，还能捕获意图。有关我们所说的意图的更多细节，请参阅参考指南中的第4章“深入CQRS和ES”。
涉及到领域专家的实现CQRS模式鼓励领域专家的参与。该模式使您能够将写端上的领域和读端上的报告需求分离出来，并将它们与基础设施关注点分离开来。这种分离使领域专家更容易参与系统中他的专业知识最有价值的方面。使用领域驱动的设计概念，如限界上下文和通用语言，也有助于集中团队的注意力，并促进与领域专家的清晰沟通。
我们的验收测试证明是一种有效的方法，可以让领域专家参与进来并获取他的知识。第4章“扩展和增强订单和注册有界上下文”详细描述了这种测试方法。
Jana(软件架构师)发言：
作为一个副作用，这些验收测试还有助于我们处理伪生产版本的快速发布，因为它们使我们能够在UI级别运行一组完整的测试，以验证除单元测试和集成测试之外的系统行为。
除了帮助团队定义系统的功能需求之外，领域专家还应该参与评估一致性、可用性、持久性和成本之间的权衡。例如，领域专家应该帮助确定什么时候手动流程是可接受的，以及在系统的不同区域中需要什么级别的一致性。
Gary(CQRS专家)发言：
开发人员倾向于将所有内容都锁定到事务中，以确保完全的一致性，但有时并不值得这样做。
现在我们已经完成了我们的旅程，我们现在可以建议您应该评估的一些标准，以确定是否应该考虑在应用程序中的一个或多个限界上下文中实现CQRS模式。您能正面回答的问题越多，就越有可能将CQRS模式应用到给定的限界上下文中，从而使您的解决方案受益：
限界上下文是否实现了业务功能的一个领域，这个领域是您的市场中的一个关键区别点?
限界上下文本质上是否与可能在运行时具有高争用级别的元素协作？换句话说，多个用户是否会为了访问相同的资源而竞争？
限界上下文是否可能经历不断变化的业务规则？
您是否已经具备了健壮的、可伸缩的消息传递和持久性基础设施？
可伸缩性是这个限界上下文面临的挑战之一吗？
限界上下文中的业务逻辑复杂吗？
您清楚CQRS模式将给这个限界上下文带来的好处吗？
Gary(CQRS专家)发言：
这些都是经验法则，不是硬性规定。
本节是我们反思我们的旅程的结果，以及确定了一些我们想以不同方式去做的事情和一些我们希望追求的其他机会。如果在我们掌握了现在我们所了解的CQRS和ES知识之后重来一次的话。
从消息传递和持久性的坚实基础设施开始