Member-only story
Improving Modular Monolith Applications with Spring Modulith
Learn how to build architecturally evident, easy to test and maintainable Modular Monolith applications with Spring Modulith and Domain Driven Design.
In the first blog of the series, we looked at how modular monolith applications can be built and implemented with Spring Boot and DDD. At the end of that blog, we identified a few limitations of the implementation. In this blog, we will try to resolve those limitations to create a more maintainable solution. We will see how Spring Modulith plays a key role. If you have not read the first blog, please read it first!
New Business Requirements
In the previous blog, we implemented an application to enable a library to borrow books by its patrons. The implementation was well-received and the library administrators are happy to switch to software for managing the borrowing process instead of maintaining the physical registry.
But soon after, the library was facing a challenge. While the application was able to handle checkouts of the book, a key aspect was missed out from the domain modeling. A request by the patrons to checkout a book would immediately mark the book as “issued”. The librarians were unable to see if the issued book was actually collected by the patron. Sometimes the patron would never come to collect and the book would remain falsely issued.
After a discussion with the domain experts, a new concept of holding a book emerged. Instead of immediately issuing a book upon a patron request, the book should be placed on hold first. Once the patron collected the book, it would be considered as issued. This will make it clear that an issued book is not in the library but with the patron.
Rethinking the Domain Model
Our current domain model consists of two subdomains Borrow and Inventory. It has been implemented with the same…
