What are your thoughts on Spring Modulith? [Java ecosystem]

Hey everyone,

I'm about to start a new corporate backend project within the Java ecosystem, and Spring Modulith has caught my attention. I'm no stranger to Spring, but I haven't seen Modulith in action yet, so I'm curious to hear your experiences with it.

Specifically, I'm interested in how event-driven communication between modules with Spring Modulith has worked out for your teams. Did you find it beneficial, or did you choose to go a different route? I'd love to hear both success stories and cautionary tales.

I really like the idea of using Spring Modulith to enforce architectural rules via tests, which is a level of structure Java doesn’t currently offer out of the box. That part seems great to me.

However, I have some reservations when it comes to the event-driven communication model between modules. Conceptually, it makes sense—event-driven communication is pretty standard in microservices. Plus, when a module matures enough to be extracted into a microservice, it already has that built-in event-driven architecture, making the transition smoother.

That said, it still feels a bit awkward. What would normally be a simple method call between services (e.g., through a DI instance or proxy) now becomes an event dispatch and consumption cycle, all within the same application but across different modules. This seems to be the preferred approach based on what I’ve gathered from the documentation.

The extra complexity this introduces raises some concerns for me:

• Under heavy load, millions of events might be bouncing between modules, adding strain to your message broker if you're using one.
• Each event would need to be persisted in the database, meaning your tables will grow and require ongoing maintenance.
• There’s added complexity in managing event consumption and handling runtime exceptions, especially if you're locking rows for consumed/unconsumed events.
• If I don't use a message broker, I'm not sure how reliable Spring's built-in messaging system would be. Anyone have insights on that?
• What happens when you deploy updates but have unconsumed events from the previous run? Either you handle it gracefully (more work) or deal with potential errors when the app comes back up (also more work).

Ultimately, I’m not fully sold on the idea of adding a persistence layer for what used to be straightforward method calls. Sure, these same issues exist in microservices, but services typically have broader responsibilities, and event communication doesn't happen as frequently as method calls in a single application.

My gut tells me that as the app grows in complexity, an event-driven approach between modules could get out of hand fast. It feels like building a bridge where there’s no water to cross. I'd likely reserve events for module-to-module communication only in cases where it’s solving a specific distributed problem or when I’m certain a module will eventually become a separate service.

But I could be wrong. What are your thoughts? Do you think the event-driven model in Spring Modulith is worth the extra complexity, or do you think it's better to stick with simpler inter-module communication until it’s absolutely necessary?