对异步通知的定位，是作为核心业务的一种补充，应该尽量与核心业务解耦。
采用的解耦方式为“事件+监听器”。一些主流的php web框架，如laravel、yii2对“事件+监听器”的支持是“开箱即用”的，只需写少量的代码（通常是增加一些配置项）即可。
这里描述的设计思想是“解耦”，是和语言无关的，属于“设计模式”的范畴。
概念
事件
业务系统在某个时机触发事件，例如订单发货了，这时需要触发一个“订单已发货”事件。事件携带了与异步通知相关的数据，如用户信息、订单信息等，这些数据用于创建异步通知任务。
监听器
监听器负责捕捉事件并创建相关的异步通知任务。
异步通知任务
异步通知任务应有以下的属性
- 接收人
- 通知内容
- 发送时间
- 发送状态
异步通知任务应带有“锁”机制，在并发场景下也可保证同一个通知不会被多次发送给用户。
异步通知的发送时间应是可配置的，以应对需求的变化。
过滤器
过滤器用于拦截不需要发送的通知。
有一种场景：用户注册后n天内不下单则发送召回通知。这种场景需要在用户注册时触发事件，监听器捕获并创建发送时间为n天后的通知任务。如果用户在n天内下单了，则这个通知就不应该发送。
这个通知对应的过滤器就应该检查从通知的创建时间到发送时间内，用户有没有下单。
实现
工厂+配置+后台进程
配置
配置包括以下内容
- 事件对应的通知节点
- 通知节点的发送时间
工厂
工厂的职责
- 创建通知任务
- 实例化通知任务
后台进程
后台进程读取待发送的通知，将通知发送给用户，并更新通知发送状态
扩展
当新需求到来时，如当用户关注的商品降价时发送一条通知，只需在业务代码中触发一个“商品降价事件”，增加相关的配置和通知节点，即可满足需求。
不足
容易看出，这种设计思想会导致业务中的事件越来越多。但为了不侵入核心业务代码，是否可以容忍这个不足之处？
