Migration examples are valuable when they show what changes in structure, not just what annotations replace which XML.

This page outlines a practical migration-style example pack that translates older J2EE-style organization into modern Spring-oriented structure without pretending the shift is only a framework swap. The real migration is architectural: clearer application services, better injection boundaries, improved testing seams, and simpler transport integration.

OOAD landing page Learning roadmap Previous: Java GoF Patterns Source Code Next: DDD Tactical Patterns Java Examples

Why This Topic Matters

Why it matters in real Java systems

Many teams still modernize systems that started with older enterprise conventions. They need examples that show how to move from service locators, heavy delegate layers, and older controller arrangements into more modern Spring application structure without losing business clarity.

Core Explanation

The main reference idea

A strong migration example set should compare the same use case before and after refactoring. For example: order submission in a J2EE-style layered flow, then the same flow in a Spring Boot style with constructor injection, application services, clearer DTO boundaries, and repository or DAO choices explained.

Concept Breakdown

Key ideas to keep in mind

Reference

Before and after

The same business flow should be shown in both styles so the change is architectural, not cosmetic.

Reference

Boundary modernization

Controller, service, DTO, and persistence boundaries should become more explicit and easier to test.

Reference

Pattern continuity

Old enterprise patterns do not disappear; they often reappear in modernized form.

Migration study sequence

Step 1

Keep the use case constant

Use one order-placement or refund flow so the comparison stays grounded.

Step 2

Modernize dependency flow

Move from lookup-heavy wiring toward constructor injection and explicit collaborators.

Step 3

Clarify business services

Separate transport, orchestration, and persistence concerns more deliberately.

Step 4

Retain historical insight

Show which old ideas still matter so modernization does not erase architectural understanding.

Java Example

Java example in the Order Management domain

Java example: constructor-injected application service after modernization

package org.javaomnibus.examples.migration;

public final class PlaceOrderApplicationService {
    private final OrderRepository orderRepository;
    private final PaymentGateway paymentGateway;

    public PlaceOrderApplicationService(OrderRepository orderRepository, PaymentGateway paymentGateway) {
        this.orderRepository = orderRepository;
        this.paymentGateway = paymentGateway;
    }
}

Code Walkthrough

Step by step

The code illustrates the architectural shift toward explicit collaborators.
What matters is not just fewer configuration artifacts. It is a more testable and readable service boundary.
Migration example packs should keep that focus throughout.
This is how the page turns modernization into design learning rather than syntax swapping.

Real-World Usage

Where this helps in practice

Enterprise modernization planning
Training teams moving from legacy Java stacks to Spring-oriented systems
Documenting architectural intent during gradual refactors

Trade-Offs

Trade-offs and when to be careful

Migration examples are highly educational, but they must resist pretending every legacy system should be rewritten into one identical target style.
The best examples show decisions and trade-offs, not just replacements.

Common Mistakes

Frequent mistakes to watch for

Reducing migration to annotation conversion
Deleting old structure without understanding what concern it once addressed
Collapsing all layers into one service class in the name of simplification
Skipping before-and-after comparisons

Related concepts

J2EE historical overview and modern equivalents J2EE vs Spring pattern mapping GoF in Spring Framework