让我先为这个很长的问题道歉。它是通过使用事件机制来实现事务性业务应用程序的模块化。
我们有一个典型的商业应用程序，允许以分开的模块组织订单，调度和接收货物：
今天，我们没有任何插件架构或类似的东西。我们的模块只是同一代码库中不同的代码文件夹。
模块是紧密耦合的，2个例子：
我们有更复杂的案例和数十（甚至数百）个模块间调用，这使得应用程序难以维护和理解。我们想改进我们的模块模型。我们希望一步一步地做到这一点（现在没有完全重写非常模块化和可插拔的方式。）
阅读一些关于模块化应用程序和减少耦合的文献，我们相信事件编程可以帮助我们。我们认为，不是直接调用其他模块，而是每个模块应该提升＆＃34;应用程序中的某些事件将被对该特定事件感兴趣的其他人捕获。
例如，订单确认模块应该提出一个＆＃34;订单确认＆＃34;订单模块捕获的事件将更新相关的订单状态。
当然，在我们的应用程序中，我们使用SQL事务来确保数据的一致性，因此我们问自己以下问题：是否应该在事务提交之前或之后引发事件？
一方面，我们必须在事务提交之前引发事件。实际上，在之前的示例中，订单状态必须在存储订单确认本身的同一事务中更新。此外，必须根据收据存储和发货标志更新来更新收到的数量。
另一方面，我们只有在确定数据被提交后才会触发一些处理，例如：发送电子邮件通知用户新确认的订单。
我们得出结论，我们需要引发2个事件：一个事务在事务提交之前，另一个事务在事务提交之后。例如，我们将有一个＆＃34;命令确认 ing 事件＆＃34;在交易中提出并且＆＃34;订单确认 ed 事件＆＃34;事务提交后引发。
订单模块将侦听第一个事件以更新订单状态，并且电子邮件通知模块将在订单确认已不可变地存储并更新订单状态后收听第二个发送通知。
我的问题是：
我们已经确定了一些递归使用该设计的限制，即。使用嵌套事务并在捕获 ing 事件的模块中引发 ed 事件。那个问题将是我们的下一个问题。
我们的应用程序是用Java开发的，但我认为这个讨论绝对是语言和框架无关的。
另请注意＆＃34;事件＆＃34;这里讨论的可以用Observer / Observable模式，任何消息排队系统（支持事务支持的同步消息传递）等替代。这只是一个实现选择，我们现在的问题更多是在设计层面。
感谢阅读直到结束：）
最好的问候