小编hse*_*sen的帖子

我无法在线找到任何在项目中使用gRPC和protobuf的"最佳实践".我正在实现一个事件源服务器端应用程序.核心定义域聚合,事件和服务,而不具有外部依赖性.gRPC服务器调用传递请求对象的核心服务,最终转换为正在发布的事件.事件使用protobuf序列化并在线上发布.我们目前处于两难境地,即我们的事件是否应该是protobuf直接生成的类,还是我们应该将核心和事件分开并实现mapper/serializer层来转换protobuf < - > core之间的事件

如果我们没有考虑另一种方法,请指导我们:)

谢谢您的帮助.

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

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

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

我已经阅读了一段时间有关事件源和 CQR 的文章，并试图找到有关使用 cassandra 作为我的事件存储和 kafka 作为发布事件的队列的帖子/读物。大多数事件溯源帖子都提到了 eventStore，并且没有对 cassandra+kafka 组合进行明确的讨论。

有人知道有关该堆栈的好阅读材料吗？或者甚至回答使用该组合的优点/缺点？似乎 cassandra 被考虑用于 cqrs 的读取部分，但没有关于使用它来持久保存事件源聚合的示例/数据模型

我们正在尝试使用可通过kafka进行异步通信的微服务来构建平台。按照我的理解，在每个微服务中每个聚合类型都有一个主题似乎是很自然的。因此，实现用户注册的微服务会将与用户相关的事件发布到主题“用户”中。其他微服务将侦听从“用户”微服务创建的事件，并实现其自己的逻辑并相应地填充其DB。问题在于，其他微服务可能对用户微服务生成的所有事件不感兴趣，而对这些事件的子集感兴趣，例如仅UserCreated（例如，没有UsernameChanged ...）。使用RabbitMq很容易，因为事件处理程序是根据消息类型调用的。

1. 您是否曾经在kafka上实现过基于消息的路由/过滤？
2. 我们是否应该使用所有消息，反序列化它们，并忽略消费者不需要的消息？（听起来像头顶的声音）
3. 我们是否应该转发这些主题以风暴并将这些消息重定向到以消费者为目标的主题？（听起来像是过度杀伤力和不可扩展的声音）
4. 使用分区作为路由机制似乎不合逻辑

越来越多的文章谈论 kafka 作为事件存储并在使用 cqrs 和事件源构建的应用程序中使用它。如何查询kafka（作为事件存储）某个聚合的事件以完成写入端的操作？