<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on Devops Monk</title><link>https://devops-monk.com/tags/architecture/</link><description>Recent content in Architecture on Devops Monk</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 03 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://devops-monk.com/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Building a Modular Monolith with Spring Modulith</title><link>https://devops-monk.com/tutorials/spring-boot/spring-boot-spring-modulith/</link><pubDate>Sun, 03 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/tutorials/spring-boot/spring-boot-spring-modulith/</guid><description>Microservices solve organizational and scalability problems — but they add operational complexity. Most applications don&amp;rsquo;t need that complexity. A modular monolith gives you clean boundaries and loose coupling without the distributed systems overhead. Spring Modulith enforces those boundaries.
The Problem with Unstructured Monoliths Without explicit boundaries, every part of the codebase can talk to every other part:
// OrderService calling PaymentRepository directly — skipping the Payment module @Service public class OrderService { @Autowired PaymentRepository paymentRepository; // ← wrong @Autowired NotificationService notificationService; // ← wrong @Autowired AnalyticsService analyticsService; // ← wrong } This creates hidden coupling.</description></item><item><title>Microservices Architecture: When to Split and When Not to</title><link>https://devops-monk.com/tutorials/spring-boot/microservices-architecture-guide/</link><pubDate>Sun, 03 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/tutorials/spring-boot/microservices-architecture-guide/</guid><description>Microservices are not a technology — they&amp;rsquo;re an organizational strategy. The right reason to split a monolith is team autonomy and independent deployment, not technical elegance. This article covers when splitting makes sense and how to do it without creating a distributed monolith.
What Microservices Actually Solve Microservices address two problems:
1. Independent deployment: Team A can deploy the Order Service without coordinating with Team B&amp;rsquo;s Payment Service. No shared deployment pipeline, no release freeze, no &amp;ldquo;all-hands&amp;rdquo; deploy windows.</description></item><item><title>Spring Modulith: Build a Modular Monolith Before You Commit to Microservices</title><link>https://devops-monk.com/2026/05/spring-modulith-guide/</link><pubDate>Sun, 03 May 2026 00:00:00 +0000</pubDate><guid>https://devops-monk.com/2026/05/spring-modulith-guide/</guid><description>Microservices solve real problems: independent deployability, team autonomy, technology flexibility. They also create real problems: distributed transactions, network latency, operational complexity. Many teams split into microservices too early, before they understand their domain well enough to draw stable boundaries.
Spring Modulith gives you module boundaries, enforced isolation, and event-driven decoupling inside a single deployable JAR. It&amp;rsquo;s the pragmatic middle ground.
The Modular Monolith Problem It Solves A typical Spring Boot monolith looks like this after a year:</description></item></channel></rss>