系统和子系统、架构和框架、模块和组件

平时学习一些编程相关的技术，除了买书看以外就是经过搜索引擎找相关资料，例如从官网上获取最新技术文档(虽然看不懂英文，可是能够借助翻译工具达到这个目的)或者是在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是为了更好的展示组织关系、权限管理等。

 

 

 

小结:

以上是我对于系统和子系统、架构和框架、模块和组件的理解(固然了，里面有我的在实际开发中的见解，同时也包含引用官方的说辞等)。

最后，该专栏做者提出了一个思考题，题目以下:

问:你原来理解的架构是如何定义的?

答：我认为我原来的理解和该专栏做者大致上是一致的，不过也许有差别。我认为架构贯穿整个软件开发生命周期(以瀑布模式为例，项目的可行性、需求分析、概要设计、详细设计、编码(代码规范制定和核心代码的编写)、测试、部署等)。不只仅包含这个还包含采用什么样的技术及其业务是所有在一个项目上(单体应用)或者分开(多体应用)等等。

这些仅仅只是我我的的见解，欢迎有更好想法的朋友留言。