事件代表過去發生的事件，事件既是技術架構概念，也是業務概念。以事件為驅動的程式設計模型稱為事件驅動架構eda。
eda是一種以事件為媒介，實現元件或服務之間最大松耦合的方式。傳統面向介面程式設計是以介面為媒介，實現呼叫介面者和介面實現者之間的解耦，但是這種解耦程度不是很高，如果介面發生變化，雙方**都需要變動，而事件驅動則是呼叫者和被呼叫者互相不知道對方，兩者只和中間訊息佇列耦合。
事件驅動有以下特徵：
生產者producer發生實時事件
推送通知
生產者發射即完成fire-and -orget
消費者consumer立即響應
事件與命令是有區別的
借助訊息系統非同步模型的特點，事件驅動也有非同步特徵，傳統方法呼叫比如呼叫b.xxmethod()是一種同步模型，這時必須等待b的方法執行完才能繼續執行其他**，rpc遠端方法呼叫也是一種同步模型，而對於非同步模型來說，事件生產者發出事件後，不必等待回應，可以繼續執行下面的**。
但是不代表使用了訊息系統的架構都是eda，soa面向服務驅動的架構中也使用訊息系統作為esb，兩者使用方式不同，三種不同互動方式：
時間驅動：比如cron定時計畫執行
請求驅動：客戶端和伺服器端之間，常見soa
.事件驅動：以事件為特徵。實時。
請求驅動+訊息系統和事件驅動+訊息系統有本質區別，前者是由請求者作為訊息生產者，主要目的是為了得到響應，因此是一種請求響應模型；而後者重點是在訊息消費者，不是在訊息生產者，業務邏輯站在消費者角度完成，業務邏輯的完成靠事件驅動來執行，而前者業務邏輯是在訊息生產者完成，當業務邏輯中需要什麼依賴或資源，依靠傳送訊息來拉取完成。這兩種區別本質是拉poll和推push的區別。
正是因為eda這種和傳統soa的本質區別，現在誕生一種領域eda，其中包括cqrs
eventsourcing
領域事件等等。同時，傳統的soa將業務領域邏輯切分成不同系統，對外表現為服務，這種方式導致業務邏輯跨越多個系統，導致業務邏輯散落各處，尋找維護不方便，造成業務邏輯的汙染和膨脹。
使用eda改造傳統soa，比如，如果乙個報表系統想知道交易系統的狀態，它不是傳送乙個訊息給交易系統，拉取它當前的狀態，而是向事件匯流排訂閱，這樣當交易系統有狀態報告時，將發出事件通知報表系統：
eda的可擴充套件性和吞吐量上要強於傳統soa，eda類似組裝生產線，下圖對於乙個順序線性的處理過程，6個步驟分別是接受 確認 儲存 產生pdf 傳送email 輸出展現，花去365ms：
詳細的組裝線如下，這實際也是一種seda，staged eda:
最終我們可以完成乙個新的基於領域事件的d-eda+soa架構如下：
來自：
事件驅動模型
事件驅動模型 問題 遇到io操作就切換 但是,什麼時候切回去了?怎麼確定io操作完了呢?傳統的程式設計是如下線性模式的 開始 塊a 塊b 塊c 塊d 結束 每乙個 塊裡是完成各種各樣事情的 但程式設計者需要知道 塊a,b,c,d的執行順序.唯一能夠改變這個流程的資料.輸入不同的資料,根據條件語句判斷...
python 事件驅動程式設計模型
event input button和text box keyboard key down和key up mouse click 和 drag timer event queue 所有的event都按照發生的先後順序存在event queue裡，先發生的event，就先執行對應的event hand...
Spring的事件驅動模型
spring事件驅動模型的三個概念 事件，事件監聽者 事件發布者。自定義事件 private string name public publishevent object source override public string tostring 自定義時間監聽者 得到event的集合 遍歷集合執...