可以通过一些具体的案例来阐述
MVC 架构已经不需要事件了
在前端的 javascript 时：JavaScript 的 MVC 模式
可以考虑使用消息机制，比如activeMQ，或者rabbitMQ。把事件写入消息队列，由消息服务器负责分发到对此话题感兴趣的监听对象上。
有不少MVC框架支持服务器端的事件，目标在于解决数据流的分层干预，比如我希望对所有的数据库写都进行过滤判断，来实现数据权限的管控。但事实上服务器端由于并不直接面向用户操作，也就是说没必要在单次请求中使用异步操作（这往往只会增加复杂性），所以上述管控用过滤器方式或继承模型并重写方法更清晰些。
而在客户端则不一样，他是面向用户操作的，1. 为了防止因处理缓慢而引起用户焦虑单个操作会采用异步处理，我们需要在处理结束或失败时做一些事，2. 前端框架由于不采用完整意义的OO设计，使得过程干预不太方便，事件就能很好解决这个问题。
居然被接受了，好，那我就补充点吧。
应用于模型层或数据驱动层：比如你正在开发一款信息系统，有需求对不同用户分配不同的客户进行管理。你可以在接到请求时判断操作的ID是否是当前用户可以操作的，但这需要开发这块的工程师去写，而实际工作中，我们希望充分的利用一个团队的所有人，分工合作，并行开发。采用事件模式后，开发常规业务的继续开发业务，他不去管这个需求，而负责这个需求的人，不用去等业务的工程师完成或去改他的代码，而是在注册某个模型的保存事件，在发生保存时就会触发这个事件，你的程序监听到这个事件时，判断这个数据是否是属于当前用户，不属于则抛出异常或返回错误。
应用于控制器，如 Servlet 监听器。比如你希望在启动时做点全局初始化的活，像激活日志系统，检查缓存什么的，你可以用 ServletContextListener。如果你正在做一个 Session 多套系统打通的工作，你可以用 HttpSessionAttributeListener 等。
事件驱动被应用最多的还是在GUI(或Web前端)上。事件是一种松散的组织结构，理论上在设计中不应该过多去干预数据流（最好仅用于做点额外的事，可以阻断后续操作但尽量不要修改正在操作的数据），如果利用的好，能有效降低模块间的耦合性，使结构更简洁，提高开发效率。