我目前正在探索领域驱动设计 (DDD)、事件溯源和 CQRS。我正在寻求澄清是否建议对事件存储和事件总线使用单个组件。文献中有多种观点，其中许多主张采用统一的组件。我关注的是可扩展性、效率以及对系统架构的影响。
我也希望获得有关适合实施此设置的最佳技术的建议。此外，如果我们选择组合事件存储和事件总线，我们如何有效地区分领域事件和系统事件？这种区别对于保持清晰度和避免事件处理中的潜在冲突似乎至关重要。
您能分享一下您在这些方面的经验或见解吗？在有选择地应用事件源的微服务环境中，我很好奇事件存储的组合解决方案可能会如何影响系统解耦和灵活性
我尝试使用 EventStoreDB 来存储事件存储和事件总线，但我现在无法区分域事件和本地服务事件
没有特定的“首选”方法来分割内部和外部的数据（这就是您所看到的）。
如果您的事件存储支持消息传递功能，您可以使用它们。如果您的目标是在有界上下文之间强烈分离数据，则您希望每个有界上下文将其数据保存在单独的存储中，并通过某些消息代理进行集成。如果您有一个团队为多个有界上下文维护软件，您可以将内容保存在一个存储中，并就特定于上下文的分离约定（如流名称前缀等）达成一致，以允许数据的逻辑分离。如果不同上下文有不同的操作要求，则将事件保存在单独的存储中是有益的，例如一个模块需要大量负载，如果它们通过共享存储集成，则可能会影响另一个模块的性能。
这里需要注意的一件事是，在单个有界上下文中集成组件不需要使用外部数据，因为它变得毫无意义。尽管您可以将软件拆分为不同组件中的一个有界上下文，但逻辑上下文边界保持不变，并且存在单个域模型。因此，当您实现涉及来自同一上下文的聚合的流程时，您不需要使用“公共事件”，也不需要外部代理组件进行集成（同样，如果您的事件存储数据库支持消息传递）。
EventStoreDB 确实提供消息传递功能。特别是，持久订阅允许您使用消费者组来实现反应式流程和流程管理器。无论如何，缺乏保证的有序交付在集成场景中不会造成伤害。
如果您确实想要使用 ESDB 跨有界上下文进行消息传递，您可以再次使用持久订阅进行转换，或使用自定义投影来实现相同目的。这两个功能都有其弱点，其中最明显的一个是写入放大，但无论如何您都希望产生新事件，因此可能不太需要担心。这些功能的最大问题目前是它们专门在领导节点上运行，该节点还支持核心事务读写负载。
您可以使用现成的第三方工具，例如 Eventulous Gateway（如果您使用的是 .NET）或实现您自己的工具。基本上，当需要内外分割时，实现总是看起来像消费 -> 转换 -> 生产。在选择举办这些公共活动的地点时，请考虑组织中的其他人使用什么进行集成。
最后要记住的一件事是分割内部和外部数据的原因。是的，有时外部事件需要比内部域事件更丰富。有时，情况恰恰相反，你想隐藏一些东西。但最重要的是，由于数据格式的原因，您希望进行拆分。公共事件模式是一个契约，而私有事件模式本质上是域模型的一部分。人们肯定不想将他们的领域模型与公共合约结合起来。