Microservice-Ready Without Microservices: Introducing Hexagonal Architecture in a Monolith

Many teams aspire to microservices but are constrained by organizational, infrastructural, or operational realities. In our case, spinning up and operating multiple services was not an option — yet our Spring Boot application kept growing, accumulating responsibilities, and blurring domain boundaries. In this session, I’ll share how we introduced Hexagonal (Onion) Architecture into an existing Spring Boot monolith to regain architectural clarity and prepare for a future microservice split — without actually building microservices yet. By restructuring the application around clear domain boundaries on a package level and enforcing architectural rules with ArchUnit, we were able to prevent new violations while systematically uncovering and refactoring existing ones. I’ll walk through concrete examples of how ArchUnit helped us make architecture an executable concept instead of a guideline, how isolating domains inside a monolith enabled independent evolution, and why this approach turned out to be a pragmatic “microservice-ready” strategy. Beyond the technical setup, I’ll also reflect on the personal learning effect: how enforcing architecture changed the way I design, code, and reason about dependencies. This talk is aimed at developers working with Spring Boot applications that are “not quite microservices” — and need a realistic path forward.