本文采用問題探究的方式來加深對spring的架構和設計原理的理解，探究的問題如下：
- 爲什麼要使用spring ioc容器？spring ioc容器和工廠模式的比較？
- spring有什麼樣的設計目標？從而採用了什麼設計理念？
爲什麼要使用spring ioc容器
在沒有引入ioc容器和對象工廠時，我們遇到的問題是：要在對象的使用者模塊中創建對象，並管理對象依賴的屬性。這樣做最大的問題是被調用的對象出現在使用者的代碼裏，使得對象的使用者和對象的耦合程度很高。同時，對象難以重用，難以細粒度地控制組裝對象的依賴組件。
看如下這個問題在各種社會形態裏如何解決:一個人(對象使用者)需要一把斧子(對象)：
(1)原始社會里，幾乎沒有社會分工。需要斧子的人(調用者)只能自己去磨一把斧子(對象)。對應的情形爲:Java程序裏的使用者自己創建對象。
(2)進入工業社會，工廠出現。斧子不再由普通人完成，而在工廠裏被生產出來，此時需要斧子的人(使用者)找到工廠，購買斧子，無須關心斧子的製造過程。對應Java程序的簡單工廠的設計模式。
(3)進入“按需分配”社會，需要斧子的人不需要找到工廠，坐在家裏發出一個簡單指令:需要斧子。斧子就自然出現在他面前。對應Spring的依賴注入。
在這個問題的演化過程中需要從使用者自己創建對象、管理對象依賴的組件裝配的流程到使用者完全不關心對象的創建和組件的裝配過程觀念轉變，這個觀念的就是：讓別人爲你服務，不再是需要什麼東西自己去造出來，而是需要什麼東西讓別人送過來，說的就是控制反轉（Inversion of Control，IOC）。對象使用者和對象徹底解耦。由此明確下控制反轉的具體含義：
- 誰控制誰：在傳統的開發模式下，我們都是採用直接 new 一個對象的方式來創建對象，也就是說你依賴的對象直接由你自己控制，但是有了 IOC 容器後，則直接由 IoC 容器來控制。所以“誰控制誰”，當然是 IoC 容器控制對象。
- 控制什麼：控制對象。
- 爲何是反轉：沒有 IoC 的時候我們都是在自己對象中主動去創建被依賴的對象，這是正轉。但是有了 IoC 後，所依賴的對象直接由 IoC 容器創建後注入到被注入的對象中，依賴的對象由原來的主動獲取變成被動接受，所以是反轉。
- 哪些方面反轉了：所依賴對象的獲取被反轉了。（摘自【死磕 Spring】—– IOC 之深入理解 Spring IoC）
設計目標和理念
Spring的設計目標是爲我們提供一個一站式的輕量級應用開發平臺，抽象了應用開發中遇到的共性問題，提供一個企業級開發的生態環境，這是和其他大部分專注於某個或某些問題領域的框架產品最大的區別。可以把spring和unix類的操作系統進行類比（這個觀點來自《spring技術內幕》一書），操作系統作爲用戶和機器之間的平臺，向用戶程序提供簡單一致的機制來控制複雜而又大相徑庭的低級硬件設備，爲用戶使用底層的硬件機器資源提供了應用開發環境，而spring是爲開發者對企業級應用資源的使用提供了技術抽象，提供了更易於使用的接口和方式。兩者從設計上都可以分爲三個層次：核心、組件、應用。
spring的核心模塊（IOC容器和AOP模塊）相當於操作系統的內核，操作系統使用進程等核心概念來抽象計算等硬件資源，爲用戶程序運行提供了抽象；對spring來說，它通過IOC容器來管理輕量級的POJO對象以及它們的耦合關係，使資源能夠很好地用java對象來抽象、描述和管理，另一方面，可以通過AOP，以動態和非侵入式的方式來增強服務的功能，自動化的通用性處理。IOC容器和AOP模塊作爲spring的核心，是實現spring生態中其它模塊的基礎。
在覈心模塊的支持下，spring提供了許多開箱即用的系統組件（事務處理、mvc、security、email、batch等等），大大簡化了企業級javaEE領域的問題，使得應用可以更關注業務邏輯的處理。由於spring本身的松耦合設計理念，可以讓應用通過簡單的開發接口或現成的應用模板就可以方便地使用這些組件和服務。
在處理與現有的優秀解決方案的關係時，它致力於爲應用提供使用優秀方案的集成平臺。正是這樣兼容幷包的平臺思維和設計理念，不斷地豐富着spring的生態系統。