1.提供明确的表述性业务概念
在某些场景下，一个业务概念会被多个流程更改，如果此属性逻辑发生变化，其他关联的流程将无法知晓，导致bug产生
如：出于性能或其他因素考虑下，为A表增加一个冗余字段，操作A业务时进行计算并赋值此字段，B表与C表业务直接使用。如果之后修改此字段且需要其他关联场景都做更改，除了一个个去找使用了此字段的地方，没有其他办法更方便的知道B表还是C表使用了，或是外部系统使用了，所以很容易产生A表冗余字段变化，但其他使用的业务忘记进行相应操作，并且一个字段可能因为多种业务操作发生变化，而关联者并不知道是什么业务导致的变化，而只能一锅粥的把所有可能都写出来，导致代码难以阅读。这也是事务脚本模式的一大弊端：一处修改处处修改，一处修改处处bug
在如上情况下，如果采用EDA方式，当然也是一处修改处处修改，可最大的区别在于，EDA提供了一个非常明确的、表述性很强的业务概念
还是如上情况，当新增或修改此字段后，发布一个对应的含有业务意义概念的事件，其他所有与此字段有业务关联的都订阅此事件
如：订单发货操作可能需要进行邮件发送、数据统计、库存修改等等等等，第一种方式需要每个地方都关注具体的数据，而EDA则只关注事件，他无需在去关注数据本身，如订单，他只关心发货操作所需要的关键数据，订单号、发货时间、快递公司等少量数据，他很明确此次只针对发货业务进行对应处理
2.