Patterns And Modern Frameworks

Patterns and Modern Frameworks

Purpose

Answer two questions that cause a lot of wasted work: does the framework already do this?, and what does this pattern look like in modern Java?

Both failures are common. Rebuilding a pattern the framework provides produces a wrapper that is worse than what it wraps. Assuming a pattern is present when it is only partly present produces a design that relies on a guarantee nobody makes — an identity map assumed to be a cache, a unit of work assumed to span a request, a repository assumed to protect an aggregate.

The map

Mechanism substantially provided — configure before rebuilding
    Front Controller         DispatcherServlet / router
    Unit of Work             JPA persistence context
    Identity Map             first-level cache
    Lazy Load                ORM proxies
    Metadata Mapping         JPA annotations / orm.xml
    Template View            Thymeleaf and friends
    Plugin                   conditional bean registration
    Registry                 the application context (used well: injection)

Provided, partial — the mechanism exists, the design decision does not
    Repository               Spring Data gives the implementation; the
                             aggregate boundary and the interface's shape
                             are still yours
    Service Layer            @Transactional gives demarcation; what a use
                             case is remains a design decision
    Optimistic Offline Lock  @Version detects; the conflict experience,
                             the retry policy and bulk-update safety are
                             yours
    Data Mapper              JPA maps; whether the domain may diverge from
                             the schema is your choice

Not provided — you must design it
    Domain Model organisation, aggregate boundaries and invariants
    Remote Facade granularity
    Pessimistic Offline Lock across requests
    Coarse-Grained Lock scope
    Application Controller flows
    Session state placement
    Distribution boundaries and saga design

Workflow

1. Before implementing a pattern, locate it in the map. If the mechanism exists, compare its actual guarantees and extension points before wrapping or rebuilding it.
2. For the second group, separate mechanism from decision. The framework supplies the mechanism; the decision is still yours and is where the value is.
3. Inspect the actual toolchain, dependencies and configuration: Java release, provider, transaction manager, proxy/weaving mode, context lifetime and enhancement where relevant. Do not infer guarantees from annotation names or upgrade to match an example.
4. Express the pattern in modern Java where the language now does the work — records for value objects and DTOs, sealed interfaces for closed hierarchies, exhaustive switch for dispatch.
5. Do not force a modern idiom where it changes the pattern's intent. A record cannot be a mutable aggregate root; a sealed hierarchy is not a plugin point.
6. When a pattern looks obsolete, separate the idea from its implementation. Most classical patterns have been absorbed, not refuted — the idea still explains the framework's behaviour.

Decision rules

The framework provides the pattern completely
        → configure it first; add a wrapper only for a demonstrated semantic boundary.

The framework provides the mechanism, you own the decision
        → make the decision explicitly and write it down. This is where
          the pattern knowledge actually pays.

The framework provides something similar with different guarantees
        → read the guarantee. Context-local identity is not cross-context caching;
          context lifetime is integration-dependent; bulk updates need explicit
          version participation.

The framework does not provide it
        → design it, using the pattern as the starting point rather
          than the answer (pattern-selection-and-composition).

A pattern's classical implementation conflicts with a modern idiom
        → keep the intent, change the implementation. Immutability,
          records and sealed types usually express the intent better.

A pattern appears obsolete
        → check whether it was absorbed rather than refuted. Table
          Module's idea survives as set-based SQL; a Row Data Gateway
          must still own row persistence, not just carry projection data.

Rules

• Do not mechanically wrap a framework abstraction. A CacheService over the caching abstraction, a TransactionService over @Transactional, an HttpService over RestClient — each adds a name, removes features, and will not survive replacing the framework anyway unless it narrows capability, owns domain semantics, translates failures or provides a genuine replacement/test seam (enterprise-architecture-smells).
• Spring Data does not decide your aggregate boundary. It generates an implementation. Which aggregates exist, what the repository's surface is, and whether reads go through it remain design decisions and are the whole content of the pattern (repository-pattern).
• A transaction-scoped persistence context is the common unit-of-work lifetime. Extended contexts and Open Session In View can outlive one service transaction; evaluate their explicit consistency, query and connection behavior rather than calling every longer scope inherently worse (orm-behavioral-patterns).
• The first-level cache provides context-local identity. It lasts with the persistence context, which need not end at transaction completion. It does not provide freshness or thread safety. Cross-context caching requires an explicit cache/provider and invalidation contract (caching-strategies).
• @Version implements managed-entity conflict detection. The client's original version, conflict presentation, valid retry and bulk SQL participation remain application concerns (offline-concurrency-control).
• JPA does not require public JavaBean setters. Portable entities need a public/protected no-arg constructor and a valid field or property access strategy. Field access supports mutation through domain methods; persistent fields must not be final (domain-logic-organization).
• Records are often effective for immutable values, DTOs, commands and events. They are not JPA entities and do not fit aggregates that require in-place mutation/proxying, but aggregate state is not mutable “by definition”; immutable replacement/event-sourced models exist.
• Sealed interfaces plus exhaustive switch give a closed hierarchy with compile-checked handling. That is better than a Special Case subclass where callers must distinguish, and worse where they must not (enterprise-base-patterns).
• Virtual threads make thread-per-task blocking designs competitive for I/O-heavy Java services; they do not make them a universal default. Pinning, native calls, downstream capacity, memory and framework support still decide. They change none of these patterns; what they change is the sizing arithmetic around them (thread-sizing-and-virtual-threads). A pattern that was chosen to avoid blocking a platform thread may be worth revisiting; one chosen for a domain reason is not.
• A pattern absorbed by a framework is still worth understanding. The framework's surprising behaviours are the pattern's classical consequences, and someone who knows the pattern predicts them instead of debugging them.

For the proposed implementation, return the framework mechanism and its verified scope, the application responsibility it leaves open, and a targeted test of the relevant gap (for example rollback, context lifetime, stale-client writes or cache interception). When configuration evidence is missing, state the assumption and how to verify it; do not present the feature as an established guarantee. Keep the response proportional to the task.

References

• What the framework already provides — pattern by pattern: what Spring and JPA implement, what they guarantee, the gap between the classical pattern and the framework's version, and the wrapper to avoid in each case. Read before implementing any classical pattern in a Spring stack.
• Modern Java expression — records, sealed types, exhaustive switch, immutability and virtual threads applied to the enterprise patterns: where they express the intent better, where they conflict with it, and the persistence constraints that decide which. Read when writing a pattern in current Java, or when modernising an old implementation.