问题标签 [cqrs]

我的团队正在开始实施一个新的应用程序，需要多租户。我一直在对简单可扩展性的模式进行大量研究，特别是在基于分布式云的基础架构上，CQRS 似乎是当前的流行语（甚至被称为“Crack for Architecture Addicts”，我觉得这很有趣）。撇开好处和缺陷不谈，除了 Greg Young 之外，很难找到任何人在生产应用程序中广泛（或完全）使用了这个想法，并且可以为它提供现实世界的指导。

所以这是我的问题： 1. CQRS 架构是否适合您的典型多租户应用程序，还是更适合更大规模的内部企业应用程序。2. 如果你建议在这种情况下使用它，你能否提供一些关于方法的从头到尾的指导 - 特别是关于早期正确的事情，以及应该有机地发展哪些方面。3. 如果有人尝试过并且发现它太难或没有意识到它的好处，或者有强烈的反对意见（并建议坚持 CRUD 和分层设计），我也想知道这些经验。

作为参考，该应用程序将使用 .NET 编写，前端最初将基于 Web (ASP.NET MVC)，可能会扩展到移动和胖客户端。预计并发性、交易活动和数据量在应用程序的整个生命周期内都将保持相对较低（与大容量金融应用程序等相比）。对于基础架构，我们计划使用 Azure。

最近一直在看一些 Greg Young 的视频，我试图理解为什么对域对象上的 Setter 持消极态度。我认为域对象应该是 DDD 中的“重”逻辑。网上有没有关于坏例子的好例子，然后他们有办法纠正它？任何例子或解释都是好的。这仅适用于以 CQRS 方式存储的事件还是适用于所有 DDD？

我一直在阅读 CQRS 并发现许多原则很有价值。但是，我有一个主要的争论点。许多人谈论让读取模型查询直接映射到视图模型 dto。到目前为止，一切都很好。但是，我经常听到的“一个表或一个视图一个选择”从何而来？当然，有些屏幕非常容易映射 1-1。但我经常使用一些复杂的屏幕，这些屏幕会涉及对下拉列表中的参考数据、小部件等的多项选择...

我可以很容易地看到我的视图需要多个选择，也许有些需要加入或两个。

除了处理您的视图简单而扁平的完美世界场景之外，您如何避免这种情况？

我一直在研究 CQRS，但我发现它在显示命令结果时会受到限制，比如说 Web 应用程序。

在我看来，使用 CQRS，一个人被迫刷新整个视图或部分视图以查看更改（使用第二个请求），因为原始命令请求将仅存储要在将来处理的事件。

在 Web 应用程序中，命令请求是否有可能将它创建的事件的结果传送回浏览器？

我现在正在研究 CQRS，我看到了一些源代码（Greg Young 的 SimpleCQRS 和 Mark Nihjof 的）。我仍然对命令和域事件感到困惑。我们是否总是需要将域持久化以在域事件处理程序中“写入数据库”？如果我调用代码将域保存到命令处理程序中的数据库（通常通过域存储库），然后让域事件处理程序处理其他内容（例如：更新读取模型和执行其他服务，如电子邮件通知），这是否常见。谢谢。

我最近开始研究 CQRS 和 DDD 以用于我即将开始的绿地项目。我从 Udi Dahan、Greg Young、Mark Nijhof 和其他人那里学习了大量材料。这些真的很有帮助，我想我对这些概念有很好的理解。但是，我仍然有一些关于如何将这些应用到我自己的领域的问题。

我的系统基本上是一个复杂的规则引擎——规则将决定某些产品的最终价格。产品定义和规则将由管理员输入系统。管理员将使用一组预定义的属性来设计规则，这些属性可以具有来自预定义集合的值，例如“购买目的”（转售、出租）或自由形式的值，例如Age。

每个产品都有一个基本价格，如果适用，规则基本上会从基本价格中添加/删除。

一个非常简单的示例规则可能是：

对于产品 X，如果（购买目的 = 转售和年龄 > 25）将 25 美元添加到基本价格。

所以有两种用户使用系统，管理员，他们定义产品、规则和基准价格；以及根据他们通过假设 UI 输入的场景查询定价的其他用户。

我的困惑是：运行一个场景根本不会改变域的状态，没有其他外部系统/人对场景执行的结果感兴趣，但运行用户他/她自己 - 它返回价格的结果在运行给定场景的适用规则后进行计算。例如，用户可以选择产品 X并查询给定场景的定价，例如（购买目的 = 转售和年龄 = 40）. 同样，由于这个操作根本不会改变域状态，我猜它是一个查询。但是，有一个规则引擎在场景上运行来计算最终价格，我猜这可以归类为正在运行的域逻辑。那么 - 这个逻辑属于哪里？这是一个仅适用于读取模型的查询，还是运行一个需要在域模型中运行的命令的场景？再一次，感觉域层是这些规则的地方，但是我如何将场景执行的结果传递给用户（感觉就像一个查询以这种方式思考它）。或者，CQRS 不是解决这个特定问题的正确方法？

假设我们有受 CQRS 启发的架构，其中包含命令、领域模型、领域事件、读取模型 DTO 等组件。
当然，我们可以在我们的领域模型中使用值对象。我的问题是，它们是否也可以用于：

1. 命令
2. 活动
3. DTO

我还没有看到在上述组件中使用值对象 (VO) 的任何示例。相反，使用原始类型。也许这只是简单的例子。毕竟，我对在 DDD 中使用 VO 的理解是它们充当了整个应用程序的粘合剂。

我的动机：

命令。
假设用户提交了一个包含地址字段的表单。我们有地址值对象来表示这个概念。在客户端构建命令时，无论如何我们都应该验证用户输入，当它格式正确时，我们可以在那里创建地址对象并用它初始化命令。我认为无需将 Address 对象的创建委托给命令处理程序。

领域事件。
领域模型已经根据值对象进行操作，因此通过使用 VO 发布事件而不是将它们转换为原始类型，我们可以避免一些映射代码。我很确定在这种情况下使用 VO 是可以的。

DTO。
如果我们的查询端 DTO 可以包含值对象，则可以提供更多的灵活性。例如，如果我们有 Money 对象，我们可以选择以 EUR 或 USD 显示它，无需更改读取模型。

鉴于实现 CQRS 的一些建议提倡相当接近金属查询实现，例如直接针对数据库的 ADO.NET 查询（或者可能是基于 LINQ 的 ORM），尝试和单元测试是否是错误的他们？

我想知道它是否真的有必要？

我对此事的看法：

1. 提供可模拟的“细读层”的额外架构复杂性似乎与将架构仪式保持在最低限度的建议的本质相反。
2. 有效覆盖用户可能编写的每个查询角度的单元测试数量是可怕的。

具体来说，我正在一个 ASP.NET MVC 应用程序中尝试 CQRS，我想知道是否需要对我的控制器操作方法进行单元测试，或者只是测试域模型。

提前谢谢了。

强调事件的架构中的命令和事件有什么区别？我能看到的唯一区别是命令通常是由系统外部的参与者获取/调用的，而事件似乎是由系统中的处理程序和其他代码获取的。但是，在我见过的许多示例应用程序中，它们具有不同（但功能相似）的接口。

我正在寻找一些具有合理单元测试集的深入的端到端 CQRS 示例。

此外，如果有人也知道一些 CQRS 截屏视频，那将非常方便。

我已经知道这些例子

• CQRS 信息
• 超级简单的 CQRS