架构实战营模块一 - 总结

什么是架构？

模块 VS 组件

模块：按照逻辑分类，进行业务分类

组件：按照物理分类，可复用单元及组建，公共代码库，代码框架

架构 VS 框架

软件架构：结构+准则+描述

软件框架：组建规范的软件产品，springboot

架构有哪些？MVP 微服务

框架有哪些？spring springboot 等

MVC 既是框架又是架构，MVC 本身定义组件规范，例如 springMVC，按照MVC 规范设计系统就是架构。

4R 架构

rank：架构是分层的，是软件系统的顶层结构

role：系统的角色定位

relation：角色之间的关系

rule：系统在不同角色之间的运作规则

从汽车的案例来理解架构

这个就是逻辑架构，其中发动机就是个角色，同时也是个物理架构。

image.png

架构师职责

• 确定不同人员层级

• 拆解角色和模块

• 定义角色间关系

• 确定角色运作规则

image.png

如何画出优秀的架构图

• 常见架构图分类

• 常见架构图画法

4+1 架构视图

• 逻辑视图：类图和状态图

• 处理视图：序列图和活动图

• 开发视图：包图

• 物理视图：部署图

• 场景视图：用例图

实际生活中，很少使用 4+1 来描述。UML 太过于抽象，不够直观

常见架构图介绍和画法

常见架构主要按照下面来进行架构图设计：

第一层 业务架构

第二层 技术领域框架（代码可以参考这个方式来进行代码库管理）

1 业务架构

业务领域管理，细化业务领域的模块，一定上对应后端的模块划分？

注意：区块的长短有什么含义没？无，排版而已。

image.png

2.1 客户端架构 &前端架构

逻辑划分进行逻辑架构划分，主要是按照团队做逻辑模块隔离。

image.png

2.2.1 后端(技术/系统)架构

MongoDB 架构图为例，简单系统只需要一个架构图即可。

image.png

复杂系统可以用两张图来展示，功能示意图（角色划分） + 交互示意图（角色关系） 即可。

image.png

2.2.2 应用架构

应用和逻辑的角色不是一一对应的，功能示意图不是应用架构！！！

image.png

MongoDB 和 HBASE 的应用架构图示例，直到开发、测试和运维的日常工作。这里的 MongoDB 的功能和应用是一致的，所以可以通用。

image.png

2.2.3 部署架构

物理部署视图，运维主要使用。

image.png

系统序列图案例

系统架构图需要通过序列图展示，是可以通过系统序列图看到角色之间的运作关系。

image.png

系统架构图与系统序列图对比如下，但是日常的序列图时仅仅需要对核心功能进行划分。

image.png

什么是面向复杂度架构设计？

1.常见的架构设计方法论

2.理解面向复杂度架构设计

面向复杂度架构设计

image.png

架构设计环

image.png

如何做好架构设计？

1.理解架构设计三原则

2.如何应用架构设计三原则

架构设计三原则

合适原则

合适的才是最好的，什么样子才是合适的？

• 资源：人力/技术水平/物理资源成本限制

• 时间：业务时间要求，公司时间要求

• 满足业务发展需求

简单原则

奥卡姆剃刀：若无必要，勿增实体

复杂度：外部复杂度（中间图，复杂在关系），内部复杂度（右边图，关系简单但是单独服务逻辑复杂）

image.png

演化原则

演化由于一步到位

• 创造快速满足需求

• 迭代优化

• 量变引起质变，重构

image.png

架构设计原则具体应用

优先级：1 > 2 > 3

image.png