系統和子系統、架構和框架、模塊和組件

平時學習一些編程相關的技術，除了買書看以外就是經過搜索引擎找相關資料，例如從官網上獲取最新技術文檔(雖然看不懂英文，可是能夠藉助翻譯工具達到這個目的)或者是在CSDN、博客園、思否、infoQ等網站獲取一些編程語言/技術框架等知識。固然了，記得初學編程的時候，大多就是去w3cschool和菜鳥教程學習，一來以爲實用性相對比較強，二來比較系統。

這週一在極客時間買了一個知識付費專欄叫作《從0開始學架構》，初看感受還不錯，因而接連下來看了8章，以爲仍是有必定的收穫。

讀了《從0開始學架構》，對第一篇文章架構究竟是什麼很有啓發，下面我給你們說說系統和子系統、架構和框架、模塊和組件。

 

1、系統和子系統

你們對於系統和子系統這個概念想必都有所瞭解。固然了，也有很多十分清楚的。

1.以人體爲例，簡單闡述系統的含義

人體由運動系統、神經系統、內分泌系統、循環系統、呼吸系統、消化系統、泌尿系統、生殖系統八大系統構成。

你能夠理解爲人體是一個系統，而運動系統、神經系統、內分泌系統、循環系統、呼吸系統、消化系統、泌尿系統、生殖系統 能夠理解爲它的子系統。

 

2.再以我曾經在校開發的博客爲例，闡述子系統的含義

個人博客就是一個系統，在這個系統裏面，它有用戶系統、文章系統、留言系統、聊天系統等。而用戶系統、文章系統、留言系統、聊天系統則屬於子系統。

 

2、架構和框架

1.架構是什麼(以軟件爲例)

軟件架構（software architecture）是一系列相關的抽象模式，用於指導大型軟件系統各個方面的設計。 軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的鏈接則明確和相對細緻地描述組件之間的通信。在實現階段，這些抽象組件被細化爲實際的組件，好比具體某個類或者對象。在面向對象領域中，組件之間的鏈接一般用接口(計算機科學)來實現。 軟件體系結構是構建計算機軟件實踐的基礎。與建築師設定建築項目的設計原則和目標，做爲繪圖員畫圖的基礎同樣，一個軟件架構師或者系統架構師陳述軟件構架以做爲知足不一樣客戶需求的實際系統設計方案的基礎。

也許用這麼官方的語言來形容，你可能不會明白。

若是我換一種方式表達，你或許就懂了。

好比:

 

(1)從開發規範的看:

Java開發常說的三層架構（界面層、業務邏輯層、數據訪問層）或者是MVC模式開發。

 

(2)從物理部署的角度看:

能夠用一張圖來表示,以下所示:

 

(3)再以我寫的書的思惟導圖爲例，如圖:

 

 這也是一個架構，只不過是一本書的架構。

 

 

 2.框架是什麼

從建築學的角度看,框架（framework）是一個框子——指其約束性，也是一個架子——指其支撐性。是一個基本概念上的結構，用於去解決或者處理複雜的問題。

以Spring框架爲例，爲何須要Spring框架，由於在沒有Spring以前，咱們對於對象的管理方式，是經過手動New進行管理，而不是如今xml中bean的方式或者是Spring註解的方式來管理。

前人由於手動管理對象，吃盡了苦頭，因此開創了這一個偉大的框架，解放了Java程序員以前手動管理對象的痛苦。

任何一門技術誕生，都有其必定的必然性。好比如今有很多朋友公司沒有用傳統的SSH框架(Spring+Struts/Struts2+Hibernate)，轉用SSM(Spring+SpringMVC+MyBatis)或者是以爲SSM(Spring+SpringMVC+MyBatis)有其侷限性不符合業務的須要而轉用SpringBoot或SpringCloud。

 

3、模塊和組件

1.什麼是模塊

百度百科對這個的定義是:

(1)在程序設計中，爲完成某一功能所需的一段程序或 子程序；

(2)或指能由 編譯程序、裝配程序等處理的獨立程序單位；

(3)或指大型軟件系統的一部分。

 

模塊,又稱 構件,是可以單獨命名並獨立地完成必定功能的程序語句的集合（即程序代碼和數據結構的集合體）。它具備兩個基本的特徵：外部特徵和內部特徵。外部特徵是指模塊跟外部環境聯繫的接口（即其餘模塊或程序調用該模塊的方式，包括有輸入輸出參數、引用的 全局變量）和模塊的功能；內部特徵是指模塊的內部環境具備的特色（即該模塊的局部數據和程序代碼）。

 

最終，你能夠將其認爲是一個系統中的功能模塊，好比登陸功能模塊、文章管理模塊、留言管理模塊或者是系統監控模塊等。

 

2.什麼是組件

好比我在前端開發中經常使用的Ztree或者是MyBatis的分頁插件等，你能夠理解爲組件。一般組件是爲了實現某個目的而引用的，好比Ztree是爲了更好的展示組織關係、權限管理等。

 

 

 

小結:

以上是我對於系統和子系統、架構和框架、模塊和組件的理解(固然了，裏面有我的在實際開發中的見解，同時也包含引用官方的說辭等)。

最後，該專欄做者提出了一個思考題，題目以下:

問:你原來理解的架構是如何定義的?

答：我認爲我原來的理解和該專欄做者大致上是一致的，不過也許有差別。我認爲架構貫穿整個軟件開發生命週期(以瀑布模式爲例，項目的可行性、需求分析、概要設計、詳細設計、編碼(代碼規範制定和核心代碼的編寫)、測試、部署等)。不只僅包含這個還包含採用什麼樣的技術及其業務是所有在一個項目上(單體應用)或者分開(多體應用)等等。

這些僅僅只是我我的的見解，歡迎有更好想法的朋友留言。