Pattern vs Framework

The difference is who owns the control flow. Your code calls a library when it decides it needs it: you create an ObjectMapper and call readValue, and the library returns control to you. A framework inverts this: it owns the overall flow and calls your code at defined extension points, as Spring's DispatcherServlet calls your controller methods or JUnit discovers and runs your test methods. This is inversion of control. The consequence is coupling: a library sits behind a call site and can usually be wrapped and replaced, while a framework shapes your application's structure, lifecycle and configuration, so replacing it is a migration project rather than a local change.

No. Spring is a framework, code you depend on that calls your code, while a pattern is a reusable design idea with no code to download. The confusion arises because Spring is built from many patterns. The IoC container uses Factory Method and Abstract Factory, beans are container-managed singletons or prototypes, @Transactional and @Cacheable work through proxies, JdbcTemplate is a Template Method with callbacks, DispatcherServlet is a Front Controller using Strategy and Adapter, and ApplicationEventPublisher is Observer. Dependency injection itself is a pattern that Spring implements. Saying we use the Spring pattern therefore mixes levels: you use the Spring framework, which applies these patterns on your behalf.

The Hollywood Principle, don't call us, we'll call you, describes inversion of control. Instead of application code driving the flow and calling reusable code, the framework owns the main loop, the lifecycle and the call sequence, and calls application code at extension points such as interfaces, callbacks, annotations or configuration. Servlet containers call your filters and servlets, Spring calls your @Bean methods, listeners and controller methods, and JUnit calls @Test and @BeforeEach methods. The benefit is that concerns like request handling, transactions and lifecycle are implemented once in the framework. The cost is that your code must fit the framework's model and timing, which is why understanding its lifecycle matters.

They differ in scope and reversibility. A design pattern such as Strategy, Adapter or Observer structures a few classes and objects to solve a local problem; you can apply or remove it within one module, often in a single refactoring. An architecture pattern such as layered, hexagonal, microservices, event-driven or CQRS structures a whole system or subsystem, defining its components, their responsibilities and how they communicate. It drives quality attributes like scalability, deployability and team autonomy, and it is expensive to reverse because many components, teams and often infrastructure depend on it. Architecture patterns are realised with many design patterns; hexagonal architecture, for example, relies on Adapter at every port.

Because most surprising Spring behaviour is a pattern's consequence. @Transactional, @Cacheable, @Async and method security are implemented with proxies, so a call from one method to another in the same bean bypasses the proxy and silently skips the transaction or cache; knowing it is a Proxy tells you to move the method to another bean or call through the proxy. Default beans are singletons shared by all threads, so they must be stateless or thread-safe. Template Method and callbacks explain JdbcTemplate, and Strategy explains why customisers, converters and handler adapters are the intended extension points. Pattern knowledge turns framework magic into predictable mechanics and makes debugging much faster.

I wrap a library behind an application-owned port when replacing or upgrading it later would otherwise ripple through the code. That is the case when it is volatile, with frequent breaking API changes; vendor-specific, like a payment provider or cloud SDK; or used widely in the domain core, where its types would leak into business logic. The adapter translates types and exceptions, such as JsonProcessingException into InvalidJson, so only one class changes on migration and tests can use simple fakes. I do not wrap stable, ubiquitous libraries used at the edges, such as java.time, SLF4J or Jackson inside a controller; the extra layer adds code without reducing real risk.

Ideally the framework stays at the edges. Controllers, persistence adapters, messaging listeners and configuration use Spring freely, while the domain model is plain Java with records, value objects and domain services that can be unit-tested without a Spring context. This is the hexagonal approach: it costs some mapping and wiring, but the core survives framework upgrades and stays easy to test. In practice most teams take a pragmatic middle path, allowing annotations such as @Service and @Transactional in the application layer while keeping the domain framework-free. What matters is that any deeper coupling, such as JPA annotations on domain entities, is a conscious, recorded decision rather than accidental drift.

I start by asking what control it takes and where: does it own the request lifecycle, the domain model, data access or deployment? Then I assess fit with the target architecture and quality attributes, for example startup time and memory for serverless workloads, native-image support, observability and security. I check ecosystem maturity, release cadence, licence, community and vendor backing, CVE history, and the cost of upgrades and of leaving later. Team skills and hiring matter as much as features. I prove the critical assumptions with a time-boxed spike on a real use case, measure the results, and record the decision, alternatives and exit strategy in an ADR.