我一直在构建事件驱动的微服务。 然后，我想知道，为什么不是事件驱动的单体应用程序。
现在的缺点是可扩展性问题。我将无法为特定的流量密集型域制作副本。
但除此之外，我仍然获得许多其他好处，例如
- 最终一致性
- 我个人也发现使用正确的设置进行调试更容易，因为我可以重播事件。
- 降低复杂性。 域之间的解耦(我们仍然在文件夹中管理域(
此外，我们还有单体的优势：主要是减少DevOps。
当应用程序越来越受欢迎(因此流量更大(时，我们可以轻松地将其转换为微服务。我认为将代码从非事件驱动转换为事件驱动是最具挑战性的部分，因为它显着改变了整体架构。
我能想到的一个批评是，仅仅为了一个整体管理一个事件总线是否值得？ 如果我使用像apache kafka这样的东西，它非常昂贵且难以管理，这可能不值得。
但是，如果我使用 NATS Streaming 或 Redis 流之类的东西，它们或多或少地完成了与 apache kafka 相同的工作，但重量轻且更易于管理，那么我认为这也不是问题。
当我在谷歌上搜索时，我找不到有关这些想法的文章，所以我想知道我是否错过了一些重要的东西。
在我的新项目中，我尝试了"事件驱动的模块化单体"，到目前为止的开发体验非常棒。我还为此制作了一个事件驱动的 npm 库，以使"事件驱动架构"变得容易。消息代理上有一个相当复杂的层，通过重放功能和死信队列使发布/订阅完美无缺。它仍然是基本的，但如果有人感兴趣，请随时查看它。