如何通过Spring事件实现Maven模块间低耦合的服务调用？

Got it, let's tackle this problem where you need to call EmployeeService.findEmployee(int id) from module_B to module_A while keeping coupling as low as possible. Here are two solid approaches that align with your goal of minimizing inter-module dependencies:

方案1：基于Spring事件的请求-响应模式（完全解耦） #

This approach uses Spring's event-driven mechanism to eliminate direct dependencies between module_A and module_B. The key is to use a shared event class (preferably in a common Maven module) so neither module depends on the other directly.

步骤1：定义共享的查询事件类 #

Create an event class that carries the query parameter and a container for the result. Place this in a common module (e.g., module-common) that both module_A and module_B depend on:

public class EmployeeQueryEvent extends ApplicationEvent {
    private final int employeeId;
    private Employee result; // Stores the query result

    public EmployeeQueryEvent(Object source, int employeeId) {
        super(source);
        this.employeeId = employeeId;
    }

    // Getters and Setters
    public int getEmployeeId() { return employeeId; }
    public Employee getResult() { return result; }
    public void setResult(Employee result) { this.result = result; }
}

步骤2：在module_A中实现事件监听器 #

Module_A only needs to listen for the event and handle the query logic, with no knowledge of module_B's existence:

@Component
public class EmployeeQueryListener {
    private final EmployeeService employeeService;

    // Constructor injection (preferred over @Autowired)
    public EmployeeQueryListener(EmployeeService employeeService) {
        this.employeeService = employeeService;
    }

    @EventListener
    public void handleEmployeeQuery(EmployeeQueryEvent event) {
        // Execute the query and set the result back to the event
        Employee employee = employeeService.findEmployee(event.getEmployeeId());
        event.setResult(employee);
    }
}

步骤3：在module_B中发布事件并获取结果 #

Module_B only needs to publish the event and retrieve the result—no direct reference to module_A's services:

@Component
public class ServiceInB {
    private final ApplicationContext applicationContext;

    public ServiceInB(ApplicationContext applicationContext) {
        this.applicationContext = applicationContext;
    }

    public Employee getEmployeeFromA(int id) {
        EmployeeQueryEvent event = new EmployeeQueryEvent(this, id);
        // Publish the event (synchronous by default, so result is available immediately)
        applicationContext.publishEvent(event);
        return event.getResult();
    }
}

Why this works: Module_A and module_B only depend on the shared common module, not each other. This is the most decoupled approach, especially useful if you might later add other modules that need to handle the same query event.

方案2：基于依赖倒置原则的接口抽象 #

If you prefer a more straightforward synchronous call pattern, this approach uses abstraction to reverse the dependency direction, following the Dependency Inversion Principle (DIP).

步骤1：定义抽象查询接口 #

Again, place this in a common module to avoid direct module dependencies:

public interface EmployeeQueryApi {
    Employee findEmployee(int id);
}

步骤2：在module_A中实现接口 #

Module_A provides the concrete implementation of the interface, tying it to your existing EmployeeService:

@Component
public class EmployeeQueryApiImpl implements EmployeeQueryApi {
    private final EmployeeService employeeService;

    public EmployeeQueryApiImpl(EmployeeService employeeService) {
        this.employeeService = employeeService;
    }

    @Override
    public Employee findEmployee(int id) {
        return employeeService.findEmployee(id);
    }
}

步骤3：在module_B中依赖抽象接口 #

Module_B only depends on the abstract interface, not the concrete implementation in module_A:

@Component
public class ServiceInB {
    private final EmployeeQueryApi employeeQueryApi;

    public ServiceInB(EmployeeQueryApi employeeQueryApi) {
        this.employeeQueryApi = employeeQueryApi;
    }

    public Employee getEmployee(int id) {
        return employeeQueryApi.findEmployee(id);
    }
}

Why this works: Module_B never references module_A directly—only the shared abstract interface. This keeps coupling low and makes it easy to swap out the implementation later (e.g., if you move EmployeeService to another module).

方案对比 #

• Spring Event Approach: Best for asynchronous workflows or when you want complete decoupling (no direct dependency even on abstractions). Great for event-driven architectures.
• Interface Abstraction Approach: More intuitive for synchronous calls, easier to maintain for simple use cases, and aligns with standard Spring dependency injection practices.

Whichever you choose, the core idea is to avoid direct dependencies between module_A and module_B—instead, rely on shared abstractions or events to mediate communication.

内容的提问来源于stack exchange，提问作者user3198603