轉自： http://www.jdon.com/eda.html

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

　　EDA是一種以事件為媒介，實現元件或服務之間最大鬆耦合的方式。傳統面向介面程式設計是以介面為媒介，實現呼叫介面者和介面實現者之間的解耦，但是這種解耦程度不是很高，如果介面發生變化，雙方程式碼都需要變動，而事件驅動則是呼叫者和被呼叫者互相不知道對方，兩者只和中間訊息佇列耦合。

　　事件驅動有以下特徵：

1. 生產者producer發生實時事件
2. 推送通知
3. 生產者發射即完成fire-and -orget
4. 消費者consumer立即響應
5. 事件與命令是有區別的

　　藉助訊息系統非同步模型的特點，事件驅動也有非同步特徵，傳統方法呼叫比如呼叫b.xxmethod()是一種同步模型，這時必須等待b的方法執行完才能繼續執行其他程式碼，RPC遠端方法呼叫也是一種同步模型，而對於非同步模型來說，事件生產者發出事件後，不必等待迴應，可以繼續執行下面的程式碼。

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

1. 時間驅動：比如cron定時計劃執行
2. 請求驅動：客戶端和伺服器端之間，常見SOA
3. .事件驅動：以事件為特徵。實時。

　　請求驅動+訊息系統和事件驅動+訊息系統有本質區別，前者是由請求者作為訊息生產者，主要目的是為了得到響應，因此是一種請求響應

　　正是因為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架構如下：