Java跨模块事件驱动的核心是通过事件总线实现模块解耦，即发布者发消息、订阅者监听消息，不依赖对方具体实现；事件为POJO，监听器通过注解或接口注册，总线为单例内存注册表，需独立事件模块、明确监听归属、区分同步异步，并避免泛化。
Java跨模块事件驱动，核心是解耦模块间的直接依赖，让一个模块“发消息”，其他模块“听消息”——不需知道对方是谁、在哪、是否存活。关键不在“用什么库”，而在“怎么设计”，否则容易变成新耦合或难以调试的隐式调用链。
事件总线本质：一个中心化的发布-订阅容器
事件总线不是魔法，它就是一个维护了“事件类型 → 监听器列表”的内存注册表。发布事件时，总线根据事件类型查出所有匹配监听器，逐个同步（或异步）调用。主流实现如 Guava EventBus、Spring Event、自研轻量总线，都遵循这个逻辑。
- 事件必须是普通 Java 对象（POJO），无继承强约束，但建议带明确语义命名（如 UserRegisteredEvent、OrderShippedEvent）
- 监听器是普通方法，用注解（如 @Subscribe）或接口实现（如 ApplicationListener
）注册，不暴露具体类名给发布方 - 总线实例通常为单例（Spring 中默认 singleton），确保所有模块共享同一事件通道
跨模块落地的关键设计点
模块间边界清晰，才能真正解耦。光靠总线不够，还需约定和结构支撑：
- 事件定义独立成包：新建 xxx-event 模块（或 jar），只含事件类与基础接口，被所有业务模块依赖。避免 A 模块改个字段，B 模块编译失败
- 监听器归属明确：谁消费谁实现。例如订单模块发布 PaymentCompletedEvent，库存模块提供监听器扣减库存，营销模块另写监听器发优惠券——两者互不知晓
- 同步 vs 异步需显式声明：默认同步调用最简单，适合低延迟、强一致性场景；异步（如用线程池或消息队列桥接）适合耗时操作，但要处理失败重试、顺序、幂等
- 避免事件过度泛化：不要定义一个 GenericEvent 扛所有业务，会丢失类型安全和可读性；也不要为每个 setter 都发事件，聚焦“业务语义完成”节点
Spring Event 的典型用法（零配置起步）
如果你项目已用 Spring，无需引入第三方，ApplicationEventPublisher + @EventListener 即可开箱即用：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 定义事件：public class UserLoginSuccessEvent extends ApplicationEvent { ... }
- 发布事件：注入 ApplicationEventPublisher，调用 publishEvent(new UserLoginSuccessEvent(user))
- 监听事件：任意 Bean 中写方法，加 @EventListener 注解，参数即事件类型，Spring 自动匹配
- 进阶控制：加 @Async 异步执行；用 @EventListener(condition = "#event.status == 'SUCCESS'") 做条件过滤
什么时候不该用事件总线？
不是所有通信都适合事件驱动：
- 模块间有强事务一致性要求（如转账必须同时更新余额与流水），优先用本地事务+领域服务，而非发事件后补偿
- 调用需要返回值或阻塞等待结果，事件天生是“发完即弃”，此时应走 RPC 或本地接口
- 模块物理隔离度高（如不同 JVM、微服务），应升级为分布式消息中间件（Kafka/RocketMQ），事件总线仅适用于单体或模块化单 JVM 架构
基本上就这些。事件驱动不是银弹，但用对了，能让模块像乐高一样插拔组合——关键在定义好“插口”（事件）、管住“连接方式”（总线）、守住“谁负责哪一段”（职责分离）。
