Before moving to Developer Relations, I transitioned from Software Architect to Solution Architect long ago. It’s a reasonably common career move. The problem in this situation is two-fold: You know perfectly well software librariesYou don’t know well infrastructure components It seems logical that people in this situation try to solve problems with the solutions they are most familiar with. However, it doesn’t mean it’s the best approach.

More than a decade ago, I wrote about the DTO: A data transfer object is an object that carries data between processes. The motivation for its use is that communication between processes is usually done resorting to remote interfaces, where each call is an expensive operation.

Spring Boot is a huge success, perhaps even more so than its inceptors hoped for. There is a lot of documentation, blog posts, and presentations on Spring Boot. However, most of them are aimed toward a feature, like monitoring or configuring. Few - if any of them, describe real-world practices. In this post, I’d like to highlight how to design a Spring Boot having multiple modules.