CQRS + ES - 在哪里查询业务逻辑所需的数据？

Question

我正在使用CQRS + ES,我有一个无法找到解决方案的建模问题.
您可以跳过下面的内容并回答标题中的一般性问题:您在哪里查询业务逻辑所需的数据？
对不起,原来这是一个复杂的问题,此刻我的思绪扭曲了!
问题在于:
我的用户是团队成员.这是一对多关系.每个用户都有每个团队的可用性状态.
团队会收到每张都有一定负载系数的门票,这些门票应根据其可用性和总负载分配给团队成员之一.
第一个问题,我需要查询团队中可用的用户列表,并选择负载最少的用户,因为他有资格获得分配.(注意这是其中一种情况,它可能是一个不同的查询运行)
第二个问题,故障单的负载因子可能会改变,所以我必须在计算每个用户的总负载时考虑到这一点.注意虽然票证可以属于1个团队,但是分配应该基于用户总负载而不是他对该团队的负载.
目前,这个有界上下文接收到TicketReceivedEvent,我应该触发工作流将该票证分配给用户.
可能的解决方案:

1. 最简单的方法是对事件进行排队并顺序发送命令AssignTicketToUser,并让服务查询用户id的读取模型,获取用户和user.assignTicket(Ticket).收到TicketAssignedEvent后,发送下一个赋值命令.但是从命令处理程序中查询读取模型似乎是一个红旗!和排队所有这些门票的麻烦!
2. 为每个用户提供一个流程管理器,其可用性/团队和分配给该用户的票证.在这种情况下,我们通过"进程管理器查找"查询将查询替换为读取端,命令处理程序将调用Ticket.AssignTo(用户).问题是我认为太多的业务逻辑泄露在域模型之外,特别是我们从User聚合中提取所有信息/模型以使其可用于查询

我倾向于使用第一个解决方案,它似乎更容易维护,修改/扩展和定位代码,但也许有一些我缺少的东西.

Answer 1

始终（嗯，99.99% 的情况）位于业务/域层，即 CQRS 的“命令”部分。这意味着您的存储库应该具有用于​​特定查询的方法，并且您的持久性模型应该足够“可查询”以实现此目的。这意味着在决定如何实现持久性之前，您必须更多地了解域的用例。

使用文档数据库（mongodb、raven db 或 postgres）可能会让工作更轻松。如果您受困于 RDBMS 或键值存储，请创建查询表，即写入模型的读取模型，充当索引:)（假设您正在序列化对象）。如果您要存储与每种实体类型的特定表模式相关的内容（巨大的开销，使您的生活变得复杂），那么可以轻松地自动查询该信息。