系統和子系統、架構和框架、模組和元件
平時學習一些程式設計相關的技術，除了買書看之外就是通過搜尋引擎找相關資料，例如從官網上獲取最新技術文件(雖然看不懂英文，但是可以藉助翻譯工具達到這個目的)或者是在CSDN、部落格園、思否、infoQ等網站獲取一些程式語言/技術框架等知識。當然了，記得初學程式設計的時候，大多就是去w3cschool和菜鳥教程學習，一來覺得實用性相對比較強，二來比較系統。
這週一在極客時間買了一個知識付費專欄叫做《從0開始學架構》，初看感覺還不錯，於是接連下來看了8章，覺得還是有一定的收穫。
讀了《從0開始學架構》，對第一篇文章架構到底是什麼頗有啟發，下面我給大家說說系統和子系統、架構和框架、模組和元件。
一、系統和子系統
大家對於系統和子系統這個概念想必都有所瞭解。當然了，也有不少十分清楚的。
1.以人體為例，簡單闡述系統的含義
人體由 ofollow,noindex">運動系統 、神經系統、 內分泌系統 、 迴圈系統 、 呼吸系統 、消化系統、 泌尿系統 、 生殖系統 八大系統構成。
你可以理解為人體是一個系統，而 運動系統 、神經系統、 內分泌系統 、 迴圈系統 、 呼吸系統 、消化系統、 泌尿系統 、 生殖系統 可以理解為它的子系統。
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。
三、模組和元件
1.什麼是模組
百度百科對這個的定義是:
(1)在程式設計中，為完成某一功能所需的一段程式或 子程式 ；
(2)或指能由 編譯程式 、裝配程式等處理的獨立程式單位；
(3)或指大型軟體系統的一部分。
模組,又稱 構件 ,是能夠單獨命名並獨立地完成一定功能的程式語句的集合（即程式程式碼和資料結構的集合體）。它具有兩個基本的特徵：外部特徵和內部特徵。外部特徵是指模組跟外部環境聯絡的介面（即其他模組或程式呼叫該模組的方式，包括有輸入輸出引數、引用的 全域性變數 ）和模組的功能；內部特徵是指模組的內部環境具有的特點（即該模組的區域性資料和程式程式碼）。
最終，你可以將其認為是一個系統中的功能模組，比如登入功能模組、文章管理模組、留言管理模組或者是系統監控模組等。
2.什麼是元件
比如我在前端開發中常用的Ztree或者是MyBatis的分頁外掛等，你可以理解為元件。通常元件是為了實現某個目的而引用的，比如Ztree是為了更好的展現組織關係、許可權管理等。
小結:
以上是我對於系統和子系統、架構和框架、模組和元件的理解(當然了，裡面有個人在實際開發中的看法，同時也包含引用官方的說辭等)。
最後，該專欄作者提出了一個思考題，題目如下:
問:你原來理解的架構是如何定義的?
答：我認為我原來的理解和該專欄作者大體上是一致的，不過也許有差異。我認為架構貫穿整個軟體開發生命週期(以瀑布模式為例，專案的可行性、需求分析、概要設計、詳細設計、編碼(程式碼規範制定和核心程式碼的編寫)、測試、部署等)。不僅僅包含這個還包含採用什麼樣的技術及其業務是全部在一個專案上(單體應用)或者分開(多體應用)等等。
這些僅僅只是我個人的看法，歡迎有更好想法的朋友留言。