oop soa cbd

• 面向對象編程(Object-Oreinted Programming) 是一種編程範式。指在設計程序時大量運用類實例對象的方式。OOP一旦在項目中被運用，就成了時刻要考慮的東西。
• 面向服務架構(Service-Oreinted Architecture) 是將軟件設計成一組可互操做的服務的一套原則或方法論。一般在考慮系統架構時纔會觸及SOA。
• 基於組件開發(Component-Based Development) 是一種軟件工程實踐，設計時一般要求組件之間高內聚，鬆耦合。其接口多是OO的，調用方式多是以Service的方式。基於組件開發關注系統層次、子系統邊界和子系統間通信的的設計，處於代碼層面但不像OOP的同樣是時刻須要運用的東西。

 

面向XX就是爲了解決系統成長過程當中遇到問題，而採用的一些範式。
舉例來講：你開始給一個企業作MIS系統。
當這個企業來很小的時候，用簡單的面向對象編程，數據庫+服務端+瀏覽器已經知足需求。不須要考慮面向組件開發和SOA.

慢慢的，這個企業長大了，當初簡單的mis系統，變得愈來愈複雜和龐大。系統中有不少重複功能的代碼。當這些功能模塊的業務有變化時是你頭疼的時候：代碼中有不少地方要修改，遇到新員工，有時老是改不全。系統上線問題愈來愈多，需求響應時間也愈來愈長。常常被客戶罵：他X的，這麼簡單的需求搞了半個月都上不了線。去年xxxxxxx兩天就上線了。
此時，你會考慮怎麼把系統中那些重複的代碼統一塊兒來。你會考慮到組件化，即「面向組件」。你把一個個比較獨立的業務模塊約定好接口，開發成組件。之後再有相似的功能模塊，直接調用這個組件，即節省開發成本，又容易維護。

後來，企業變成了集團公司。已經上線了不少套各類各樣的mis系統。雖然大部分系統都實現了組件化。但作爲一個集團公司，仍然有不少共同的業務，不一樣mis系統中有不少功能重複的模塊。此時又面臨業務升級困難，難以使用的問題：一個需求可能要涉及不少套mis系統的升級。同時每套系統都有獨自的界面，客戶錄入一個數據，要打開N個頁面，要登錄N次，叫苦連天。各類數據不一致的問題接踵而來。
SOA來啦。架構師把各個系統功能相似的模塊抽象成服務，重複的模塊再也沒有了，不一樣系統間互相調用服務接口。之前要本身寫一大堆代碼，如今搞清楚接口，直接調用另外一套Mis系統的服務接口就 OK了。也有了單點登錄，有了portal，有了搜索服務，有了知識庫等等。

可是問題又來了：
總有一些很重要的服務，全部的系統都會依賴它，它出一點問題，全部系統都停轉。你開始考慮雙機，熱備，負載均衡。
之前用的IBM的主機+Oracle數據庫+EMC的存儲，再後來買更貴的性能更好的。慢慢的你發現，企業掙的錢都他媽的給了IOE。你開始考慮分佈式，開始考慮使用開源產品。