Spring Modulith - Spring for the Architecturally Curious Developer by Oliver Drotbohm

The architecture and design of an application significantly influences its maintainability, testability, and quality in general. Spring has always been a versatile tool that supports architects implementing the practices and patterns that have emerged to align technical building blocks in their code bases with domain concepts and boundaries. It lets developers build applications that clearly reflect architectural ideas and that are ultimately more amendable and maintainable. Key aspects of that are code organization for encapsulation, the Spring bean relationship arrangement, and how to use domain events to decouple logically individual parts of the application even within a singular artifact.
The talk discusses those patterns and approaches to introduce Spring Modulith to, in turn, show how they uniquely position Spring developers to build better structured, more maintainable applications.

[@rohitsaxena3710]

Spring modulith should be a game changer in a sense it tries to overcome cons of both monolithic and microservices architecture.
1. Everything is within the same spring application, hence avoids management of number of microservices (though data layer would be same, but its good as it doesn't require synchronization of databases among microservices).
2. Forces strong dependency management to avoid injecting other modules in a single module and allows event based communication between modules. This is similar to have microservices based patterns within a single application.

[@ggunlistedarchive969]

Maybe more like: improving monoliths by taking ideas from microservices.

[@ogyct]

I am still struggling to this day what to do the simple stuff. Like storing relational entities of a kind: book, author. Let's say I want to save a book. Where should I put Book and Author entities. Should it be one package, or two. What class will be responsible for create a book, fetching an author and storing at a related entity. All those complex architecture patterns don't answer such a simple question.

[@breun]

You could look into Domain-Driven Design's concept of bounded contexts and how to define them.

[@rustinpeace7466]

This seems like a real neat way to enforce architecture. I didn't catch if it is applicable to an existing codebase? Like could I slap it in one of my company's EJB's and it suggest how to modularize?