Business Delegate Pattern

Business Delegate gives presentation or client layers a simple local interface while hiding remote service or business-tier complexity behind a focused adapter.

Why This Topic Matters

Why it matters in enterprise Java

In enterprise flows, web layers should not know about remote EJB semantics, transport quirks, retry behavior, or service lookup details. A delegate keeps those concerns out of the caller.

Pattern Essentials

Intent, problem, and solution

Intent

What the pattern is trying to achieve

Reduce coupling between callers and business-service implementation or lookup details.

Problem

What goes wrong without it

Presentation code becomes tightly coupled to remote service APIs, lookup protocols, or infrastructure error handling.

Solution

How the pattern answers the problem

Introduce a delegate that exposes a simpler interface and translates infrastructure concerns on behalf of the caller.

Modern Relevance

Why it still matters now

The pattern still appears when wrapping remote clients, partner SDKs, and legacy infrastructure APIs for cleaner use by modern application layers.

Structure

How the collaboration works

Caller depends on a delegate rather than a raw remote or infrastructure-heavy service.
The delegate locates or receives the real business service.
The delegate translates infrastructure-specific failures or awkward protocols.
Caller remains cleaner and more stable.

Java Example

Java example in the Order Management domain

Java example: order summary delegate shielding the web layer

package org.javaomnibus.ecommerce.business;

public final class OrderSummaryDelegate {
    private final OrderSummaryClient client;

    public OrderSummaryDelegate(OrderSummaryClient client) {
        this.client = client;
    }

    public OrderSummary loadSummary(String orderId) {
        try {
            return client.fetch(orderId);
        } catch (RemoteClientException ex) {
            throw new OrderAccessException("Could not load order summary", ex);
        }
    }
}

Code Walkthrough

Step by step

The caller sees a stable local API.
Remote or integration exceptions are translated into application-specific failures.
Transport-level details stay out of controllers or presentation models.
The delegate remains useful only if it stays thin and purposeful.

Real-World Usage

Where this pattern shows up

Shielding web layers from legacy remote business services
Wrapping awkward client SDKs or generated service stubs
Creating stable application-facing APIs over volatile infrastructure clients

When Not To Use

Cases where another shape is better

Simple in-process services where DI already provides a clean boundary
Cases where the delegate adds nothing except pass-through method forwarding

Trade-Offs

Trade-offs and design pressure

Delegates help isolate infrastructure concerns, but they are extra layers that must stay meaningful.
Too many pass-through delegates can make service flow harder to trace.

Comparison Note

How this differs from nearby patterns

Business Delegate is a caller-facing shield. Session Facade is a coarse-grained business boundary. Service Locator centralizes lookup and often sits behind a delegate in legacy systems.

Common Misuse

Mistakes to avoid

Creating a delegate for every service even when no translation or shielding is needed
Putting business rules into the delegate instead of the application or domain service
Using it as a naming upgrade for a pass-through wrapper

Related concepts

Service Locator Session Facade Web Service Broker