0

我正在开发一组程序集，这些程序集封装了我们域的一部分，将由许多应用程序共享。使用订单管理系统的示例，一个这样的程序集将包含应用程序可以对订单执行/对订单执行的所有核心操作。我们正在应用一个简单版本的 CQS/CQRS，以便所有更改“系统”状态的操作都表示为公共命令，例如 CancelOrderCommand、ShipOrderCommand 和 CreateORderCommand。命令处理程序在程序集内部。

我正在努力回答的问题是如何最好地将读取模型暴露给消费代码？

读取模型将通过使用代码来执行查询。我不知道如何使用读取模型的所有方式，因此接口需要灵活以允许任何查询。

对我来说复杂的是，我不仅需要公开我的聚合根，而且还有几个客户端应用程序可能使用的相关数据的“查找”列表。例如，每个订单都有一个关联的 OrderType，它是数据驱动的（即，不是枚举），并包含几个属性，这些属性将驱动我们的一些业务规则，这些规则控制可以/不可以执行的操作等。在我的内部很容易管理这种关系的模块；但是，允许创建订单的客户端应用程序很可能需要向用户显示可能的 OrderType 列表。因此，我不仅需要从我的读取模型中公开 Order 聚合列表，还需要公开 OrderTypes 的支持列表（和其他查找列表）。

这通常是如何完成的？

我不确定还有什么可以解释这将有助于触发解决方案，所以请询问...

4

1 回答 1

0

我从未见过基于 CQRS 的实现公开了用于临时查询的完整数据集，所以这是一个有趣的情况！在典型的 CQRS 场景中，您将公开非常具体的查询，因为您可能希望在调用事件时引发事件（例如缓存 -有关详细信息，请参阅这篇文章）。

但是，由于这是您的设计，我们不必担心“典型”或“正确”CQRS，我想您只需要一个解决方案！我见过的公开数据以进行灵活查询的最佳新机制之一是开放数据协议 (OData)。它将允许消费者在您公开的数据源上实现自己的过滤、排序和分页。

大多数实现似乎都处理关系数据。如果您正在处理关系数据源，那么 OData 可能是一个不错的选择。我怀疑您对“公开我的聚合根”的评论可能正在使用文档数据库？如果是这样，我在 MongoDB 上看到了一个 OData 服务示例：http: //bloggingabout.net/blogs/vagif/archive/2012/10/11/mongodb-odata-provider-now-supports-arrays-和-nested-collections.aspx。

我希望这会有所帮助，OData 绝对值得研究。它的增长似乎非常迅速，并且在服务器和客户端技术平台上都得到了很好的支持。

于 2013-03-25T12:00:08.147 回答