1.提供明確的表述性業務概念

在某些場景下，一個業務概念會被多個流程更改，如果此屬性邏輯發生變化，其他關聯的流程將無法知曉，導致bug產生

如：出于性能或其他因素考慮下，為A表增加一個冗余字段，操作A業務時進行計算并賦值此字段，B表與C表業務直接使用。如果之后修改此字段且需要其他關聯場景都做更改，除了一個個去找使用了此字段的地方，沒有其他辦法更方便的知道B表還是C表使用了，或是外部系統使用了，所以很容易產生A表冗余字段變化，但其他使用的業務忘記進行相應操作，并且一個字段可能因為多種業務操作發生變化，而關聯者并不知道是什么業務導致的變化，而只能一鍋粥的把所有可能都寫出來，導致代碼難以閱讀。這也是事務腳本模式的一大弊端：一處修改處處修改，一處修改處處bug

在如上情況下，如果采用EDA方式，當然也是一處修改處處修改，可最大的區別在于，EDA提供了一個非常明確的、表述性很強的業務概念

還是如上情況，當新增或修改此字段后，發布一個對應的含有業務意義概念的事件，其他所有與此字段有業務關聯的都訂閱此事件

如：訂單發貨操作可能需要進行郵件發送、數據統計、庫存修改等等等等，第一種方式需要每個地方都關注具體的數據，而EDA則只關注事件，他無需在去關注數據本身，如訂單，他只關心發貨操作所需要的關鍵數據，訂單號、發貨時間、快遞公司等少量數據，他很明確此次只針對發貨業務進行對應處理

2.