<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Spring Modulith on SivaLabs</title><link>https://www.sivalabs.in/tags/spring-modulith/</link><description>Recent content in Spring Modulith on SivaLabs</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 02 Sep 2026 15:01:28 +0530</lastBuildDate><atom:link href="https://www.sivalabs.in/tags/spring-modulith/index.xml" rel="self" type="application/rss+xml"/><item><title>A Few Hard Learned Lessons On Structuring Spring Boot Applications</title><link>https://www.sivalabs.in/blog/a-few-hard-learned-lessons-on-structuring/</link><pubDate>Fri, 12 Jun 2026 04:59:17 +0530</pubDate><guid>https://www.sivalabs.in/blog/a-few-hard-learned-lessons-on-structuring/</guid><description>&lt;p&gt;One of the most common questions developers ask when starting a Spring Boot project is:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;How should I structure my code?&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;If you spend enough time in Java circles, you&amp;rsquo;ll quickly run into recommendations like &lt;strong&gt;Clean Architecture, Hexagonal Architecture, Onion Architecture, Ports and Adapters&lt;/strong&gt;, and a dozen variations of the same idea.&lt;/p&gt;
&lt;p&gt;Now, before anyone gets upset: I think those architectures solve real problems.&lt;/p&gt;
&lt;p&gt;The issue is that many teams adopt them on day one, long before they actually have those problems.&lt;/p&gt;</description></item></channel></rss>