事件代表過去發生的事件，事件既是技術架構概念，也是業務概念。以事件為驅動的編程模型稱為事件驅動架構EDA。

EDA是一種以事件為媒介，實現組件或服務之間最大松耦合的方式。傳統面向接口編程是以接口為媒介，實現調用接口者和接口實現者之間的解耦，但是這種解耦程度不是很高，如果接口發生變化，雙方代碼都需要變動，而事件驅動則是調用者和被調用者互相不知道對方，兩者只和中間消息隊列耦合。

事件驅動有以下特征：

生產者producer發生實時事件

推送通知

生產者發射即完成fire-and -orget

消費者consumer立即響應

事件與命令是有區別的

借助消息系統異步模型的特點，事件驅動也有異步特征，傳統方法調用比如調用b.xxmethod()是一種同步模型，這時必須等待b的方法執行完才能繼續執行其他代碼，RPC遠程方法調用也是一種同步模型，而對于異步模型來說，事件生產者發出事件后，不必等待回應，可以繼續執行下面的代碼。

但是不代表使用了消息系統的架構都是EDA，SOA面向服務驅動的架構中也使用消息系統作為ESB，兩者使用方式不同，三種不同交互方式：

時間驅動：比如cron定時計劃執行

請求驅動：客戶端和服務器端之間，常見SOA

.事件驅動：以事件為特征。實時。

請求驅動+消息系統和事件驅動+消息系統有本質區別，前者是由請求者作為消息生產者，主要目的是為了得到響應，因此是一種請求響應模型；而后者重點是在消息消費者，不是在消息生產者，業務邏輯站在消費者角度完成，業務邏輯的完成靠事件驅動來執行，而前者業務邏輯是在消息生產者完成，當業務邏輯中需要什么依賴或資源，依靠發送消息來拉取完成。這兩種區別本質是拉Poll和推Push的區別。

正是因為EDA這種和傳統SOA的本質區別，現在誕生一種領域EDA，其中包括CQRSEventSourcing?領域事件等等。同時，傳統的SOA將業務領域邏輯切分成不同系統，對外表現為服務，這種方式導致業務邏輯跨越多個系統，導致業務邏輯散落各處，尋找維護不方便，造成業務邏輯的污染和膨脹。

使用EDA改造傳統SOA，比如，如果一個報表系統想知道交易系統的狀態，它不是發送一個消息給交易系統，拉取它當前的狀態，而是向事件總線訂閱，這樣當交易系統有狀態報告時，將發出事件通知報表系統。

EDA的可擴展性和吞吐量上要強于傳統SOA，EDA類似組裝生產線，下圖對于一個順序線性的處理過程，6個步驟分別是接受 確認 保存 產生PDF 發送Email 輸出展現，花去365ms：

而組裝線的EDA方式，總是詢問著6步中是否可以讓別人協同幫助完成？其中第4步和第5步是可以的，因此整個處理時間提升到115ms，提升了70%的響應時間：

詳細的組裝線如下，這實際也是一種SEDA，Staged EDA:

最終我們可以完成一個新的基于領域事件的D-EDA+SOA架構如下：