平时学习一些编程相关的技术,除了买书看之外就是通过搜索引擎找相关资料,例如从官网上获取最新技术文档(虽然看不懂英文,但是可以借助翻译工具达到这个目的)或者是在CSDN、博客园、思否、infoQ等网站获取一些编程语言/技术框架等知识。当然了,记得初学编程的时候,大多就是去w3cschool和菜鸟教程学习,一来觉得实用性相对比较强,二来比较系统。

这周一在极客时间买了一个知识付费专栏叫做《从0开始学架构》,初看感觉还不错,于是接连下来看了8章,觉得还是有一定的收获。

读了《从0开始学架构》,对第一篇文章架构到底是什么颇有启发,下面我给大家说说系统和子系统、架构和框架、模块和组件。

一、系统和子系统

大家对于系统和子系统这个概念想必都有所了解。当然了,也有不少十分清楚的。

1.以人体为例,简单阐述系统的含义

人体由运动系统、神经系统、内分泌系统循环系统呼吸系统、消化系统、泌尿系统生殖系统八大系统构成。

你可以理解为人体是一个系统,而运动系统、神经系统、内分泌系统循环系统呼吸系统、消化系统、泌尿系统生殖系统 可以理解为它的子系统。

2.再以我曾经在校开发的博客为例,阐述子系统的含义

我的博客就是一个系统,在这个系统里面,它有用户系统、文章系统、留言系统、聊天系统等。而用户系统、文章系统、留言系统、聊天系统则属于子系统。

二、架构和框架

1.架构是什么(以软件为例)

软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个或者对象。在面向对象领域中,组件之间的连接通常用接口(计算机科学)来实现。 软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

也许用这么官方的语言来形容,你可能不会明白。

如果我换一种方式表达,你或许就懂了。

比如:

(1)从开发规范的看:

Java开发常说的三层架构(界面层、业务逻辑层、数据访问层)或者是MVC模式开发。

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

可以用一张图来表示,如下所示:

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

(3)再以我写的书的思维导图为例,如图:

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

 这也是一个架构,只不过是一本书的架构。

 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是为了更好的展现组织关系、权限管理等。
 
 
 

小结:

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

最后,该专栏作者提出了一个思考题,题目如下:

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

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

这些仅仅只是我个人的看法,欢迎有更好想法的朋友留言。

11-24 13:43