一個優秀的架構師總是能對各種解決方案的優點和對應成本之間取得良好的平衡，而這種能力背后是架構師豐富的經驗和廣闊的知識體系。基於消息的軟件建構模型則是架構師必備的知識點，本文將詳細描述該模型的演變過程。
還記得第一次跟師傅打交道，他問我“Hi yang，你的功能設計的怎么樣了？”我有點不以為然，不就是個很小的功能么，為什么要用“設計”一詞，為什么不是“你的代碼寫的怎么樣了？”。我后來明白了，“設計”一詞代表了他對軟件的態度，在他眼中任何功能都應該是設計出來的，沒有經過設計的代碼如同流水帳一樣，只能應付眼前，久而久之代碼變得不可擴展和維護。本文會隨着架構模型的演變過程，對同一個需求進行不斷設計和演變，最終成型。
本系列文章包含以下內容：
- 三種觀察者模式的C#實現——在代碼層面實現觀察者模式
- .net中事件引起的內存泄漏分析——理解為何要使用弱引用來實現EventBus
- 響應式編程(Reactive programming)——觀察者模型的函數式實現
- EventAggregator, EventBus的實現——對MVVM light中EventBus代碼分析
- 使用Akka.net開發第一個分布式應用——使用基於Actor模型的框架開發分布式應用
- 企業服務總線(ESB)-EventBus的進一步抽象——使用NServiceBus構建高伸縮性，低耦合的分布式應用
看了這個目錄，也許有人會有疑問，為什么前三條都是在說觀察者模式和事件，這跟基於消息的架構有什么關系？
var watcher = new FileSystemWatcher();
watcher.Created += (object sender, FileSystemEventArgs e) =>
{
MessageBox.Show(string.Format("I am interesting in fileName={0} and path={1} which was created", e.Name,e.FullPath));
};
這是一段使用事件的代碼，.Net中的事件模型是一個觀察者模式，這段代碼可以描述為：觀察者(observer)-匿名lambda函數觀察了一個主題(subject)Created。每當有文件被創建的時候watcher會遍歷所有的觀察者並將主題的數據通知給觀察者。
而消息則是觀察者模式的進一步抽象。主題（subject)中的FileSystemEventArgs中包含有我們感興趣的信息，我們可以將FileSystemEventArgs理解為消息，當FileSystemWatcher發現有新文件被創建時發送一個類型為FileSystemEventArgs的消息即可，不同的組件可以訂閱這個消息獲得被創建文件的名稱和路徑等信息。當FileSystemEventArgs能夠序列化並且可以在網絡上傳輸時，不同的子系統都可以訂閱這個消息，最終演變為一個分布式系統。
最終架構圖如下：
各子系統將自己的消息發送到ESB上，同時訂閱其他系統中感興趣的消息。各子系統不再直接相互依賴，后期有新的系統直接接入ESB即可。整個架構最終演變為松耦合，高伸縮性的分布式系統。
整個系列的代碼地址：https://git.oschina.net/richieyangs/EventArchitecture