事件驱动架构在同一个应用程序中拥有向自己发送事件/命令的组件是否常见？ （请看下图）。
我在工作中遇到了这种奇怪的情况，而且看起来不太对劲。 此组件发送给自身的事件/命令示例： FILE_ARRIVED , PROCESS_FILE, FILE_PROCESSED
我显然不是事件驱动架构方面的专家。实际上，这是我为其提供服务的第一个“想成为”事件驱动系统。但我真的很感激听到你对此的想法。谢谢。
【问题讨论】：
标签： architecture event-driven event-driven-design
首先免责声明：在不了解您的应用程序域的详细信息以及如何削减服务边界的情况下，我们无法就您的具体情况向您提供任何建议。例如，服务边界可能选择不当，但作者选择该设计也可能有充分的理由。
这里有两点需要考虑：
一般来说，在内部使用事件驱动方法的组件不会是一种不常见的模式 - 虽然事件驱动架构以解决分布式系统中的微服务通信问题而闻名，但它们已在各种软件中以不同的形式使用架构。一些示例是用于进程间通信的回调注册和/或消息管道/队列。
这将我们带到第二点 - 使用外部事件总线的网络通信开销何时是合理的？当然，主要是当消息/事件被外部组件消耗时，但另一个原因可能是事件总线被用作其他瞬态组件的持久性形式。例如，在不允许丢失消息/事件的情况下，例如在崩溃、硬件故障等情况下，有动力尽快将它们发送到具有持久性的系统。
【讨论】：