Events 如何将事件编程与SQL事务混合使用？

让我先为那个很长的问题道歉。它是关于使用事件机制对事务性业务应用程序进行模块化的

我们有一个典型的业务应用程序，它允许在单独的模块中组织下单、发货和收货：

• 命令
• 订单确认
• 派遣
• 接待

今天，我们没有任何插件架构或类似的东西。我们的模块只是同一代码库中不同的代码文件夹

模块紧密耦合，2个示例：

• 存储订单确认后，订单确认模块直接调用订单模块以更新相关订单状态
• 接收时，接收模块直接呼叫发货模块，将相关发货标记为已接收，并直接呼叫订单模块，更新相关订单接收数量

我们有更复杂的情况和数十个（可能数百个）模块间调用，这使得应用程序很难维护和理解。我们希望改进我们的模块模型。我们希望一步一步地完成（目前还没有以模块化和可插拔的方式完全重写）

阅读一些关于模块化应用程序和减少耦合的文献，我们相信事件编程可以帮助我们。我们认为，与直接调用其他模块不同，它们中的每一个都应该“引发”应用程序中的某些事件，以便其他对特定事件感兴趣的人捕获

例如，订单确认模块应引发订单模块捕获的“订单确认”事件，该事件将更新相关订单状态

当然，在我们的应用程序中，我们使用SQL事务来确保数据一致性，因此我们会问自己以下问题：应该在提交事务之前还是之后引发事件

一方面，我们必须在提交事务之前引发一个事件。实际上，在前面的示例中，订单状态必须在存储订单确认本身的同一事务中更新。此外，必须根据接收存储和发送标志更新相应地更新接收数量

另一方面，只有在确定数据已提交后，我们才会触发一些处理，例如：发送电子邮件通知用户新确认的订单

我们得出结论，我们需要引发两个事件：一个在事务提交之前，另一个在事务提交之后。例如，我们将在事务中引发“订单确认事件”，并在事务提交后引发“订单确认事件”

订单模块将侦听第一个事件以更新订单状态，电子邮件通知模块将侦听第二个事件以在订单确认已永久存储且订单状态已更新后发送通知

我的问题是：

• 我们是否在这种方法中遗漏了什么
• 是否有一些规则/最佳实践来定义事件？在我们的示例中，我们有一个“订单确认”事件。我们是否应该进一步或替代“订单状态更改”事件？第一种方法更面向特征，第二种方法更面向数据，哪种方法最好
• 我们真的减少了这种方法的耦合，还是仅仅是一种错误的感觉
• 在这两种形式中是否应该使用事件来支持事务提交之前/之后的ing和ed

我们已经确定了递归使用该设计的一些局限性，即使用嵌套事务并在捕获了ing事件的模块中引发ed事件。这个问题将是我们的下一个问题

我们的应用程序是用Java和Spring开发的，但我认为这一讨论绝对与语言和框架无关

还请注意，这里讨论的“事件”可以被观察者/可观察模式、任何消息队列系统（支持事务支持的同步消息传递）等所取代。这只是一个实现选择，我们的问题现在更多地处于设计级别

谢谢你一直读到最后：）

致意