Session Facade Pattern

Why it matters in enterprise Java

Checkout, refund, and shipment flows usually involve several services. A coarse-grained application boundary keeps clients from reassembling that workflow themselves.

Intent, problem, and solution

How the collaboration works

• Client sends one business-level request.
• Facade orchestrates lower-level services and collaborators.
• Use case completes within one coarse-grained application boundary.
• Client receives a stable result instead of coordinating many steps.

Java example in the Order Management domain

package org.javaomnibus.ecommerce.application;

public final class CheckoutSessionFacade {
    private final InventoryService inventoryService;
    private final PaymentService paymentService;
    private final ShipmentService shipmentService;

    public CheckoutSessionFacade(
        InventoryService inventoryService,
        PaymentService paymentService,
        ShipmentService shipmentService
    ) {
        this.inventoryService = inventoryService;
        this.paymentService = paymentService;
        this.shipmentService = shipmentService;
    }

    public CheckoutReceipt checkout(CheckoutCommand command) {
        Reservation reservation = inventoryService.reserve(command.orderId());
        PaymentReceipt payment = paymentService.capture(command.orderId(), command.amount());
        ShipmentPlan shipment = shipmentService.plan(command.orderId(), command.address());
        return new CheckoutReceipt(reservation, payment, shipment);
    }
}

Step by step

1. The client makes one use-case level call instead of coordinating several services directly.
2. Workflow sequencing stays inside the facade boundary.
3. The facade returns a meaningful business result rather than exposing every intermediate step.
4. This keeps clients simpler and reduces chatty boundary interactions.

Where this pattern shows up

• Application services in Spring or Jakarta EE
• Coarse-grained use-case boundaries for APIs or UI layers
• Legacy remote service boundaries that need to minimize call chatter

Cases where another shape is better

• Trivial operations that do not coordinate meaningful workflow
• Situations where one facade is becoming an omnibus service for unrelated use cases

Trade-offs and design pressure

• A facade improves boundary clarity, but overgrown facades become broad service blobs.
• The trick is coarse-grained enough for the use case, but not broad enough to lose cohesion.

How this differs from nearby patterns

Session Facade resembles a modern application service. Business Delegate shields callers from access complexity, while Session Facade defines the coarse-grained business use case boundary itself.

Mistakes to avoid

• Stuffing unrelated business operations into one massive facade
• Using the facade as a pass-through wrapper with no real boundary value
• Letting controllers reproduce use-case orchestration instead of using the facade boundary

Related concepts