基于事件驱动的业务分析
而要做到同步转异步，我们必须从业务需求分析开始就转变思维，即从传统的业务流程需求分析方法转到事件驱动分析方法，这个在我很早的EDA事件驱动架构内容整理的时候专门谈到过，今天摘录部分内容供大家参考。
事件驱动框架（EDA）里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。
EDA架构往往具备如下特征：
- 广播通信：参与通信的系统将事件广播给任何对该事件感兴趣的参与者。
- 实时性：在业务事件发生时候，EDA架构下可以实时的发送事件给消费方，而无需等待
- 异步：事件发布系统不用等待事件接收系统来处理事件，发送到EDA模块即可返回。
- 细粒度：只要具备独立的业务价值，即可以发布为细粒度的事件，而不是传统服务下的粗粒度。
- 复杂事件处理：根据业务流程需求，事件间可以聚合和组装，形成事件链满足复杂事件处理。
- 并行运行：多个事件可以同时运行，单个事件可以同时分发给多个订阅方。
- 非阻塞：EDA本身提供MQ等消息持久化机制，不会在事件大并发下出现事件阻塞情况。
简单来讲，消息集成，异步，彻底解耦，消息发布订阅，事件链是EDA整个架构的核心。但是在EDA包括CEP复杂事件处理，在使用的时候首先还是应该了解清楚其和传统流程驱动在业务分析方法上的区别。简单来说，流程驱动和事件驱动的一个简单比较可以用下图描述：
基于EDA的核心业务分析思路说明
在事件驱动架构下，业务分析的核心就是事件的识别。而对于传统方法往往则是关键流程和活动即可。在总体分析思路上的变化来说，传统分析方法只分析到第2-3级业务流程，识别业务活动和交互点，而EDA需要业务分析时候分析到L4级的最底层EPC事件流程图，并识别关键业务事件和事件分解，聚合关系。
在具体分析内容上的变化来说，传统方法只关心业务活动，而不关系业务活动具体的启动机制，业务活动完成后产生的业务事件。基于EDA业务分析方法，需要打开业务活动，识别业务活动的前者触发条件和业务活动引起的业务对象状态的变化，往往状态变化点都是关键的事件识别点。
具体可以用下图进行描述：
简单事件-基于业务需求用例分析和识别
业务事件的识别可以从业务需求用例入手，分析业务用例中的业务前置触发条件，分析业务对象的状态流转过程和后续操作，以找寻业务活动的事件输入和事件产生。
从下图里面也可以看到，对于事件的识别往往比用例的识别更加细化，需要详细的分析业务用例中的基本流，扩展流，业务规则，特别是关注其中核心的业务对象和单据状态的变化。同时对于用例分析中的触发条件也需要重点分析，这些触发条件往往是事件链形成，或者说触发消息事件订阅的来源。
复杂事件-基于事件识别形成事件链
传统的基于流程的业务分析方法往往只会分析到业务流程，具体的业务活动，而不关心具体业务活动执行前或执行后产生的业务事件，这和接口平台前期重点关注数据集成有关系。而为了保证业务实时响应需求，必须准确的识别业务事件，才能进一步设计基于业务事件的处理和响应机制。
基于EPC事件流程链分析思路，需要对传统分析流程进行细化，增加红色事件识别点和事件分解聚合关系。在事件链的形成过程中往往存在一些复杂场景需要分析，包括了事件的一对多分发和订阅，也包括了多个事件聚合，在满足某个特定的业务规则后才触发下一个新的业务活动和新事件。这些都是在复杂事件分析中必须考虑的内容之一。
