例如购买一只股票，首先会校验这个交易，校验股票交易是否符合各种规定，将它交给一个经纪人，计算佣金，最后确认交易。所有这些都安排好各个步骤的顺序，决定它们是否串行还是并行。
它包括四个组件：event queues, an event mediator, event channels 和 event processors。
事件流是这样开始的： 客户端发送一个事件到事件队列(event queues)中，它用来将事件传送给event mediator。Event mediator收到初始的事件后，会发送额外的一些异步事件给event channels来执行处理的每个步骤。Event processors监听event channels,接收事件并处理一些业务逻辑。
在事件驱动架构中有十几个甚至几百个事件队列都很正常。模式本身没有限定事件队列的实现方式。它可能是一个消息队列，一个web service或者其它。
这里有两种事件：初始事件和处理事件。Mediator会将初始事件编排成处理事件。它没有具体的业务逻辑，只是一个协调者，负责将初始事件转化成一个或者多个处理事件。
event channels 既可以是消息队列，也可以是消息topic，大部分是消息topic，这样可以由多个消息处理器(event processor)处理同一个消息。
消息处理器包含实际的业务逻辑。每个消息处理器都是自包含的，独立的，高度解耦的，执行单一的任务。
这种模式可能有一些变种。作为架构师，你应该理解每个实现的细节，确保这种解决方案适合你的需求。
有一些开源的框架实现了这种架构，如Spring Integration, Apache Camel, 或者 Mule ESB。
Broker拓扑架构
Broker不同于上面的结构，它没有中心的Mediator。所有的事件串联起来通过一个轻量级的消息broker如RabbitMQ，ActiveMQ，HornetQ等。如果你的消息比较简单，不需要重新编排，就可以使用这种结构。
如图所示，它包含两个组件broker和 event processor。
broker中的event channel可以是消息队列，消息topic或者它们的复合形式。
每个event processor负责处理事件，发布新的事件。
架构例子
在新浪微薄的早期架构中，微薄发布使用同步推模式，用户发表微薄后系统会立即将这条微薄插入到数据库所有粉丝的订阅列表中，当用户量比较大时，特别是明星用户发布微博时，会引起大量的数据库写操作，超出数据库负载，系统性能急剧下降，用户响应延迟加剧。后来新浪微薄改用异步推拉结合的模式，用户发表微薄后系统将微薄写入消息队列后立即返回，用户响应迅速，消息队列消费者任务将微薄推送给所有当前在线粉丝的订阅列表中，非在线用户登录后再根据关注列表拉取微薄订阅列表。
架构考量
事件驱动架构模式实现起来相对复杂，主要是由于它的异步和分布式特性。这可能会带来一些分布式的问题，比如远程处理的可用性，缺乏响应，broker重连等问题。
一个考虑是这种模式对于单一的逻辑缺乏原子事务。所以你需要将原子事务交给一个事件处理器执行，跨事件处理器的原子事务是很困难的。
最困难的设计之一是事件处理器的创建，维护和管理。事件通常有特殊的约定(数据值和格式)。
模式分析
总体灵活性： 高
发布易用性： 高
可测试性： 低
性能： 高
规模扩展性： 高
开发容易度： 低