<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Domain-Driven-Design on dplabs — Software Engineering &amp; Technology Consultancy</title>
		<link>https://dplabs.tech/tags/domain-driven-design/</link>
		<description>Recent content in Domain-Driven-Design on dplabs — Software Engineering &amp; Technology Consultancy</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Mon, 02 Dec 2024 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://dplabs.tech/tags/domain-driven-design/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Modern Spring Boot Architecture: Beyond the Three-Layer Application</title>
				<link>https://dplabs.tech/blog/modern-spring-boot-architecture/</link>
				<pubDate>Mon, 02 Dec 2024 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/modern-spring-boot-architecture/</guid>
				<description>&lt;p&gt;The three-layer architecture — controllers, services, repositories — is how most Spring Boot tutorials present application structure. It&amp;rsquo;s a reasonable starting point. It&amp;rsquo;s also a pattern that breaks down as applications grow.&lt;/p&gt;&#xA;&lt;p&gt;The problems are predictable: services become God classes with hundreds of methods, repository calls leak into controllers, domain logic spreads across multiple layers, and changing anything requires understanding the entire application at once. The layered architecture doesn&amp;rsquo;t enforce boundaries — it suggests them. Suggestions decay under deadline pressure.&lt;/p&gt;</description>
			</item>
			<item>
				<title>The Modular Monolith: An Architecture Pattern That Deserves More Attention</title>
				<link>https://dplabs.tech/blog/modular-monolith-architecture/</link>
				<pubDate>Mon, 14 Oct 2024 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/modular-monolith-architecture/</guid>
				<description>&lt;p&gt;The software industry has a microservices fixation. Over the last decade, &amp;ldquo;monolith&amp;rdquo; became almost a pejorative, and teams moved to distributed architectures before they had the scale, team size, or operational maturity to justify them.&lt;/p&gt;&#xA;&lt;p&gt;The result has been widespread over-engineering: systems that are harder to understand, harder to debug, harder to change, and more expensive to operate — not because distributed systems are inherently bad, but because the problems they solve weren&amp;rsquo;t actually present.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
