<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Spring / Spring Boot on dplabs — Software Engineering &amp; Technology Consultancy</title>
		<link>https://dplabs.tech/categories/spring-/-spring-boot/</link>
		<description>Recent content in Spring / Spring Boot on dplabs — Software Engineering &amp; Technology Consultancy</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Mon, 21 Jul 2025 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://dplabs.tech/categories/spring-/-spring-boot/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Spring Boot Dependency Injection Without Losing Your Architecture</title>
				<link>https://dplabs.tech/blog/spring-boot-dependency-injection/</link>
				<pubDate>Mon, 21 Jul 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/spring-boot-dependency-injection/</guid>
				<description>&lt;p&gt;Spring&amp;rsquo;s dependency injection container is one of the most mature and capable DI frameworks available. It&amp;rsquo;s also capable of enabling architectures that are deeply coupled to Spring internals, impossible to test without a full Spring context, and opaque about their dependencies.&lt;/p&gt;&#xA;&lt;p&gt;The patterns that produce good Spring Boot architectures are not complicated. They require deliberate choices about when to use Spring and when to step back from it.&lt;/p&gt;&#xA;&lt;h2 id=&#34;constructor-injection-is-non-negotiable&#34;&gt;Constructor Injection Is Non-Negotiable&lt;/h2&gt;&#xA;&lt;p&gt;Spring supports three injection mechanisms: constructor, setter, and field injection. Field injection (&lt;code&gt;@Autowired&lt;/code&gt; on a field) is the most common and the worst.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Building Resilient Spring Boot Services</title>
				<link>https://dplabs.tech/blog/spring-boot-resilience/</link>
				<pubDate>Mon, 09 Jun 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/spring-boot-resilience/</guid>
				<description>&lt;p&gt;Resilience patterns exist to handle the failures that are guaranteed to occur in distributed systems. Downstream services become unavailable. Networks time out. Databases become overloaded. These are not exceptional events — they&amp;rsquo;re normal operating conditions that a production service must handle correctly.&lt;/p&gt;&#xA;&lt;p&gt;The mistake is adding resilience patterns everywhere as a precaution. A circuit breaker on a service that never fails adds overhead without value. A retry on a non-idempotent operation can cause duplicate side effects. Resilience patterns should be applied deliberately, to specific failure modes that matter for your system.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Spring Boot Observability: Metrics, Tracing, and Logs That Actually Help</title>
				<link>https://dplabs.tech/blog/spring-boot-observability/</link>
				<pubDate>Mon, 31 Mar 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/spring-boot-observability/</guid>
				<description>&lt;p&gt;Spring Boot 3.x has strong observability support built in. Spring Boot Actuator, Micrometer for metrics, Micrometer Tracing (built on OpenTelemetry), and structured logging all work out of the box with minimal configuration.&lt;/p&gt;&#xA;&lt;p&gt;The gap between &amp;ldquo;instrumented&amp;rdquo; and &amp;ldquo;observable&amp;rdquo; is wider than it looks. Adding dependencies and enabling endpoints is instrumentation. Being able to answer &amp;ldquo;why are 3% of requests failing between the payment service and the inventory service, and since when?&amp;rdquo; is observability.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Spring Boot Testing: What Should Actually Be Tested and How</title>
				<link>https://dplabs.tech/blog/spring-boot-testing-strategy/</link>
				<pubDate>Mon, 10 Feb 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/spring-boot-testing-strategy/</guid>
				<description>&lt;p&gt;Spring Boot&amp;rsquo;s testing support is extensive and well-designed. It&amp;rsquo;s also easy to misuse in ways that produce slow, fragile test suites with poor diagnostic value.&lt;/p&gt;&#xA;&lt;p&gt;The core question is not &amp;ldquo;how do I test with Spring Boot?&amp;rdquo; but &amp;ldquo;what needs to be tested, and at what level?&amp;rdquo;&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-testing-pyramid-applied-to-spring-boot&#34;&gt;The Testing Pyramid Applied to Spring Boot&lt;/h2&gt;&#xA;&lt;p&gt;The testing pyramid principle: favor many fast, isolated unit tests over fewer slow integration tests. Each level of the pyramid is slower and more expensive to run but tests more of the system.&lt;/p&gt;</description>
			</item>
			<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>
	</channel>
</rss>
