软件架构与需求分析(一)

1、软件架构体系

1.1. 系统与子系统

系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。

• 关联：发动机、底盘、轮胎、车架组合起来才能成为一台汽车，构成一个系统。
• 规则：汽车发动机负责产生动力，然后通过变速器和传动轴，将动力输出到车轮上，从而驱动汽车前进。
• 能力：汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力。

子系统：子系统也是由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。

以抖音APP为例来做一个分析：

• 本身是一个系统，包含视频、聊天、登录、支付等子系统。
• 视频这个系统又包括动态、评论、点赞等子系统。
• 评论这个系统可能又包括防刷子系统、审核子系统、发布子系统、存储子系统。
• 评论审核子系统不再包含业务意义上的子系统，而是包括各个模块或者组件，这些模块或者组件本身也是另外一个维度上的系统。例如，MySQL、Redis 等是存储系统，但不是业务子系统

1.2. 模块、组件、服务

• 模块：是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往使用模块作为合成的单位
• 组件：自包含的、可编程的、可重用的、与语言无关的软件单元，组件可以很容易被用于组装应用程序中
• 服务：服务和组件有某种相似之处：它们都将被外部的应用程序使用。两者之间最大的差异在于：组件是在本地使用的（例如Jar文件）；而服务是运行起来的，要通过同步或异步的远程接口来远程使用（例如RESTFul接口、web service、消息系统、RPC，或者socket）

模块和组件的区别：模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。

• 角度：
  • 从逻辑的角度来拆分系统后，得到的单元就是“模块”；
  • 从物理的角度来拆分系统后，得到的单元就是“组件”。
• 目的：
  • 划分模块的主要目的是职责分离；
  • 划分组件的主要目的是单元复用。

例如我们要做一个学生信息管理系统，这个系统从逻辑的角度来拆分，可以分为：登录注册模块、个人信息模块、个人成绩模块；从物理的角度来拆分，可以拆分为应用程序、 Nginx、Web 服务器、MySQL等

1.3. 软件架构体系

2. 架构原则

2.1. 解耦

在软件工程中，耦合指的就是对象之间的依赖性。对象之间的耦合度越高，维护成本越高。因此对象的设计应使类和构件之间的耦合最小。划分模块的一个准则就是高内聚低耦合。

耦合性存在于各个领域，而非软件设计中独有的，理论上说绝对的零耦合是做不到的，但可以通过一些方法将耦合降至最低，降低耦合度即可理解为解耦，在设计上解耦的核心思想是【彼此独立，互不依赖】。

例如：

• mvc， controller 依赖 service，但是依赖的 service 是接口而非具体的实现
• 数据库连接，jdbc 统一接口，然后由不同的实现来连接不同的数据库
• 消息队列，将消息的发送和接收进行解耦

2.2. 分层

分层结构是最为流行、应用最广泛的应用软件的设计方式。在应用了分层结构的系统中，各个子系统按照层次的形式组织起来，上层使用下层的各种服务，而下层对上层一无所知。每一层都对自己的上层隐藏其下层的细节。

经典三层架构：

在软件架构中，经典三层架构自顶向下由用户界面层、业务逻辑层、数据访问层组成。这种分层架构有效地隔离了业务逻辑与数据访问逻辑，使得这两个不同关注点能够相对自由和独立地演化。经典的三层架构如下所示：

2.3. 封装

在一个类中，当每个对象的状态保持相对孤立，就实现了封装。其余的对象并不能观察到这个对象的状态。他们能做到的只有调用一些被称作“方法”的通用功能。

因此，对象使用方法掌控着自己的状态，除非明确允许，没有其他人可以接触到它。如果你想和某个对象交流，你需要使用提供的方法。但在默认情况下，你无法改变对象的状态。

封装使得类或者对象只允许其他对象在自定义的规则内操作自己的属性或者方法，保证了数据的安全和可靠。

站在宏观的角度，一个模块、服务也进行了封装，它们通常提供了一系列的接口以便外部操作自身。

3. 架构的方法

架构图是为了表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。要让干系人理解、遵循架构决策，就需要把架构信息传递出去，架构图就是一个很好的载体。不同的视角和角色，关注点也是不同的，看到的架构图是不一样的。

3.1 业务架构

使用者：CEO、CIO、CTO、产品总监

3.2 功能架构

使用者：产品总监、产品经理

3.3 系统架构

使用者：系统架构师

3.4 技术架构

使用者：系统架构师

3.5 数据架构

使用者：CTO、系统架构师、数据架构师

示例一：数据模型

示例二：大数据平台架构

3.6 部署架构

使用者：运维架构师