4.2 业务代表模式

业务代表模式（Business Delegate）在表示层和业务服务层之间插入一个中间对象，把“如何找到服务、如何远程调用、如何处理底层异常”这些细节统统藏起来。表示层只和业务代表打交道，不再直接耦合具体的业务服务 API。

这是经典 J2EE 时代为应对 EJB、JNDI、远程调用复杂性而生的模式。下面的实验切换底层服务实现（EJB / JMS），注意客户端那行调用始终不变——代表把差异吸收了。

它解耦了什么

没有业务代表时，每一个表示层组件都直接 import 并调用业务服务接口、自己处理查找与远程异常。结果是：

• 表示层和业务层紧耦合，业务接口一变，前端到处要改。

• 查找、重试、异常转换逻辑重复散落在每个调用点。

业务代表把这些收拢到一处。下面的对照器让你直观看到：引入代表后，表示层 → 业务层的耦合连线数如何大幅下降。

与服务定位器搭档

业务代表自己并不负责“查找服务”，它通常委托服务定位器（4.7 节）来完成。两者职责清晰：

• 业务代表：面向表示层，提供简化的业务方法，处理远程调用的复杂性。

• 服务定位器：按名字查找并缓存服务实例。

class BusinessDelegate {
    private BusinessService service = locator.lookup("OrderService");
    public Result process(Request r) {
        return service.process(r);   // 表示层无需知道这背后的查找与远程细节
    }
}

今天还需要它吗

在依赖注入（DI）框架普及的今天，许多业务代表的职责被 DI 容器、API 客户端 SDK、网关层承接了。但它的核心思想依然鲜活：给表示层一个稳定、简化的业务入口，把基础设施的复杂性挡在门外。 微服务里的“客户端 SDK / Feign 接口”，本质就是现代版的业务代表。