微服务架构下如何解耦，对于已经紧耦合下如何重构？( 三 ) _微服务架构

文章插图

基于EDA的核心业务分析思路说明
在事件驱动架构下，业务分析的核心就是事件的识别。而对于传统方法往往则是关键流程和活动即可。在总体分析思路上的变化来说，传统分析方法只分析到第2-3级业务流程，识别业务活动和交互点，而EDA需要业务分析时候分析到L4级的最底层EPC事件流程图，并识别关键业务事件和事件分解，聚合关系。
在具体分析内容上的变化来说，传统方法只关心业务活动，而不关系业务活动具体的启动机制，业务活动完成后产生的业务事件。基于EDA业务分析方法，需要打开业务活动，识别业务活动的前者触发条件和业务活动引起的业务对象状态的变化，往往状态变化点都是关键的事件识别点。
具体可以用下图进行描述：

文章插图

简单事件-基于业务需求用例分析和识别
业务事件的识别可以从业务需求用例入手，分析业务用例中的业务前置触发条件，分析业务对象的状态流转过程和后续操作，以找寻业务活动的事件输入和事件产生。
从下图里面也可以看到，对于事件的识别往往比用例的识别更加细化，需要详细的分析业务用例中的基本流，扩展流，业务规则，特别是关注其中核心的业务对象和单据状态的变化。同时对于用例分析中的触发条件也需要重点分析，这些触发条件往往是事件链形成，或者说触发消息事件订阅的来源。

文章插图

复杂事件-基于事件识别形成事件链
传统的基于流程的业务分析方法往往只会分析到业务流程，具体的业务活动，而不关心具体业务活动执行前或执行后产生的业务事件，这和接口平台前期重点关注数据集成有关系。而为了保证业务实时响应需求，必须准确的识别业务事件，才能进一步设计基于业务事件的处理和响应机制。
基于EPC事件流程链分析思路，需要对传统分析流程进行细化，增加红色事件识别点和事件分解聚合关系。在事件链的形成过程中往往存在一些复杂场景需要分析，包括了事件的一对多分发和订阅，也包括了多个事件聚合，在满足某个特定的业务规则后才触发下一个新的业务活动和新事件。这些都是在复杂事件分析中必须考虑的内容之一。

文章插图

从EDA事件驱动到CQRS

文章插图

顾名思义，CQRS即命令查询职责分离，将CUD操作和R查询操作分离，对于CUD操作仍然参考传统的领域模型建模思路来实现，但是在命令中增加了消息事件机制，实现CUD操作变更通过消息事件异步写入到数据库。
在CQRS中，查询方面，直接通过方法查询数据库，然后通过DTO将数据返回，这个方面的操作相对比较简单。而命令方面，是通过发送具体Command，接着由CommandBus来分发到具体的CommandHandle来进行处理，CommandHandle在进行处理时，并没有直接将对象的状态保存到外部持久化结构中，而仅仅是从领域对象中获得产生的一系列领域事件，并将这些事件保存到Event Store中，同时将事件发布到事件总线Event Bus进行下一步处理；接着Event Bus同样进行协调，将具体的事件交给具体的Event Handle进行处理，最后Event Handler把对象的状态保存到对应Query数据库中。

文章插图

对于CQRS，最容易想到的还是在数据库层面做的读写分离模式，可以看到CQRS本身和数据库的读写分离模式可以更好的匹配，由于采用事件驱动和消息订阅模式，对于R读库我们可以更加容易对数据变更信息进行更新，达到读库数据的及时同步更新。同时读库既可以采用读写分离数据库，也可以采用类似Solr，Nosql等分布式，非结构化数据来实现弹性水平扩展能力。
在命令查询职责没有分离的时候，可以看到一方面是模型本身的扩展性受到影响，另外一方面是原有的领域模型本身偏重，而且Entity实体本身也通过完整的DTO对象进行传输，这样在一些特殊的只需要更新或查询个别字段的时候，整个模型仍然偏重。
通过命令查询职责的解耦，不仅仅是提升整个框架模型的扩展性，更加重要是将两类业务规则和实现彻底的解耦开，方便后续的功能开发和运维，特别是在整个业务场景和逻辑实现复杂的情况下，这种解耦会使整个开发架构更加清晰简单。