1. 课程导入
大家好，我是这门课的主讲。今天咱们聊聊事件驱动架构——这个在UI开发里越来越重要的概念。
说实话，我刚开始做前端那会儿，项目里全是传统的MVC模式。后来接手一个大型后台系统，数据流乱成一锅粥，改一个按钮要翻遍十几个文件。那时候我才意识到，架构选型真的能决定一个项目的生死。
什么是事件驱动架构
事件驱动架构（Event-Driven Architecture，简称EDA），核心思想很简单：当某个事情发生时，系统发出一个事件，其他对这个事件感兴趣的模块自己去响应。
你想想看，这就像办公室里有人喊了一声「开会了」。喊的人不需要知道谁去、谁不去，也不需要挨个通知。想参会的人听到声音自己就过去了。这就是事件驱动的本质——发布者与订阅者解耦。
在UI领域，事件可以是用户点击、数据加载完成、表单验证通过、组件挂载完毕……任何「发生了某件事」都可以是一个事件。
// 一个简单的事件驱动示例
// 发布事件
eventBus.emit('user:login', { userId: 123, name: '张三' })
// 订阅事件
eventBus.on('user:login', (data) => {
console.log(`用户 ${data.name} 已登录`)
// 更新UI、请求数据、记录日志……
})嗯，这里要注意：事件驱动不是某个框架的专利。Vue的$emit、React的合成事件、Redux的dispatch，本质上都是事件驱动的变体。只不过我们这门课要讲的是架构层面的事件驱动，不是某个API的用法。
与传统MVC的区别
传统MVC（Model-View-Controller）大家应该都熟悉。我当年刚入行时，MVC就是金科玉律。但做得久了，你会发现它有几个硬伤。
| 对比维度 | 传统MVC | 事件驱动架构 |
|---|---|---|
| 通信方式 | Controller直接调用Model和View | 模块之间通过事件总线通信 |
| 耦合度 | 高耦合，Controller知道所有模块 | 低耦合，发布者不知道订阅者是谁 |
| 数据流 | 单向或双向绑定，路径固定 | 事件流，路径灵活 |
| 扩展性 | 新增功能需要修改Controller | 新增订阅者即可，不影响现有代码 |
| 调试难度 | 调用栈清晰，容易追踪 | 事件流分散，需要工具辅助 |
| 适用规模 | 中小型项目 | 中大型、复杂交互项目 |
我在项目中遇到过这样一个场景：一个电商后台的订单列表页，用户点击「取消订单」后，需要同时更新列表状态、发送通知、记录日志、刷新统计数据。用MVC的话，Controller里要写一大串调用代码。换成事件驱动，只需要发一个 order:cancelled 事件，各个模块自己去处理就行了。
核心优势
事件驱动架构到底好在哪？我总结了几点，都是实际项目中实打实的好处。
- 解耦彻底——模块之间不需要知道对方的存在。你发你的事件，我收我的事件，互不干扰。
- 扩展方便——想加一个新功能？写个新模块，订阅已有事件就行。老代码一行都不用改。
- 异步友好——事件天然适合异步场景。用户操作、网络请求、定时任务，都能用事件串联起来。
- 可测试性强——每个事件处理器都是独立的函数，单独测试非常容易。
- 逻辑清晰——业务逻辑被拆分成一个个事件处理器，每个处理器只做一件事。
适用场景
根据我的经验，下面这些场景特别适合用事件驱动架构：
- 复杂表单——字段联动、校验、自动保存、依赖加载
- 仪表盘/看板——多个数据源实时更新，图表之间互相关联
- 工作流系统——审批、流转、通知、状态变更
- 多人协作工具——编辑、同步、冲突处理、实时推送
- 插件化架构——核心功能稳定，外围功能可插拔
说白了，只要你的UI里存在「一个操作影响多个模块」的情况，事件驱动就能派上用场。
核心知识体系
下面这张图，是我梳理的事件驱动架构核心知识体系。你可以把它当作这门课的地图。
这张图展示了事件驱动架构的核心脉络：事件总线作为中枢，连接发布者和订阅者。发布者只管发事件，订阅者只管处理事件，彼此不知道对方的存在。下面四个特性——解耦、可扩展、异步、可测试——是事件驱动最大的价值所在。
好了，第一章就到这里。事件驱动架构的概念其实不复杂，但真正用好它，需要大量的实践和思考。接下来的章节，我会带你从零开始，一步步搭建一个完整的事件驱动UI系统。咱们下章见。