文章目录
软件设计原则与分层
一. 软件设计原则
1.1 单一职责原则
永远不应该有多于一个原因来改变某个类
理解:对于一个类而言,应该仅有一个引起它变化的原因
应用:如果一个类拥有了两种职责,那就可以将这个类分成两个类
1.2 开放封闭原则
软件实体扩展应该是开放的, 但对于修改应该是封闭的
理解:对扩展开放,对修改封闭.可以去扩展类,但不要去修改类
应用:当需求有改动,尽量用继承或组合的方式来扩展类的功能,而不是直接修改类的代码
1.3 里氏替换原则
Class 面向对象原则
理解:父类一定能够被子类替换
1.4 最少知识原则
只与你最直接的对象交流
理解:低耦合,高内聚.
应用:做系统设计时,尽量减少依赖关系
1.5 接口隔离原则
一个类与另一个类之间的依赖性,应该依赖于尽可能小的接口.
理解:不要对外暴露没有实际意义的接口.用户不应该依赖它不需要的接口
应用:当需要对外暴露接口时, 如果是非必要对外提供,尽量删除.
1.6 依赖倒置原则
高层模块不应该依赖于低层模块,他们应该依赖于抽象.抽象不应该依赖于细节,细节应该依赖于抽象
理解: 应该面向接口编程, 不应该面向实现类编程.
并不是说,所有的类都要有一个对应的接口,而是说,如果有接口,那就尽量使用接口来编程.
总结:
将以上六大原则的英文首字母拼在一起就是SOLID(稳定的), 所以也称之为SOLID原则.
只要满足了这六大原则,才能设计出稳定的软件架构!
二. 补充设计原则
2.1 组合/聚合复用原则
当要扩展类的功能时, 优先考虑使用组合,而不是继承.
该原则在23种经典设计模式中频繁使用.
如:代理模式, 装饰模式,适配器模式等.
2.2 无环依赖原则
当A模块依赖于B模块,B模块依赖于C模块,C模块依赖于A模块,此时将出现循环依赖.
在设计中避免该问题, 可通过引入中介者模式解决
2.3 共同封装原则
应该将易变的类放在同一个包里,将变化隔离出来.
该原则是"开放-封闭原则"的延生.
2.4 共同重用原则
如果重用了包中的一个类,那么也就相当于重用了包中的所有类,我们要尽可能减少包的大小
2.5 好莱坞原则
Don’t call me, I’ll call you.
“控制反转”(或称为"依赖注入")
不需要主动创建对象,而是由容器帮我们来创建并管理这些对象.
2.6 不要重复你自己
不要让重复的代码到处都是,要让他们足够的重用,所以要尽可能的封装
2.7 保持它简单与傻瓜
保持系统界面简洁,功能实用,操作方便.
2.8 高内聚低耦合
模块内部需要做到内聚度高, 模块之间需要做到耦合度低.
2.9 关注点分离
将一个复杂问题分离为多个简单的问题, 然后逐个解决.
难点: 如何进行分离? 分离的颗粒度,分离的原则
2.10 你不需要它
不要一开始就把系统设计得非常复杂, 不要陷入"过渡设计"的深渊.
让系统足够简单,而不失去扩展性
注意设计原则使用,以及在日常开发中使用
三. 软件设计分层
3.1 系统级架构
应用在整个系统内,如与后台服务如何通信, 与第三方系统如何集成.
设计前端首要条件:了解前端系统与其他系统之间的关系.
关系包括:业务关系和协作机制.
设计后端:只需要规定与后台数据传递的机制.
包括:api设计规则, 访问授权的一个开放标准(OAuth)跳转token的验证, 数据传递cookies的等.
前后端分离架构其实就是如何实施技术决策,用户鉴权,API接口管理和设计,API文档管理,MOCK的使用,BFF(服务于前端的后端,nodejs),是否需要服务端渲染等.
3.2 微前端
- 在一个系统内微前端是应用间的架构方案
- 在多个应用之间,微前端则是一种系统间等架构方案
- 微前端是将多个前端应用以某种形式结合在一起进行应用
- 旨在解决单体应用在一个相对长的时间跨度下,由于参与的人员,团队的增多,变迁,从一个普通应用演变为一个巨石应用(Frontend Monolith)后,随之而来的应用不可维护的问题.
单实例:即同一时刻,只有一个子应用被展示, 子应用具备一个完整的应用周期形式
多实例:通常基于url的变化来做子应用的切换.
多实例:同一时刻可展示多个子应用
通常使用Web Components方案做子应用封装,子应用更像是一个业务组件而不是应用.
3.3 应用级架构
应用级别架构可以看作是系统级架构的细化
单个应用与其他外部应用的关系, 微服务架构下多个应用的协作, 数据交换等.
- 脚手架
- 模式库
- 设计系统
3.4 模块级别架构
在开始业务编码之前进行设计,称之为迭代
3.5 代码级架构
规范与原则
实操
- 开发流程
- 代码质量以及改善
- 规范而非默契
注:
-
- 在开发中,要注意可维护性.
-
- 简单的代码可维护性高;越是写的抽象的代码越难维护
注意可维护性与扩展性
四. 如何保证架构的质量—稳定性与健壮性
4.1 如何保证架构的质量?
系统的稳定性?
当一个实际的系统处于一个平衡状态时候,如果受到外来作用影响时,系统经过一个过渡过程仍然能够回到原来的平衡状态,
我们称这个系统就是稳定的,否则称系统不稳定.
- 架构设计的基石
- 可以更好的实现自我修复
系统健壮性?
计算机软件在输入错误,磁盘故障,网络过载,或者有意攻击情况下,能否不死机,不崩溃,就是该软件健壮性的具体表现
解释:一个系统容错能力强,运行不易被干扰,安全性好
度量标准
一个软件可以从错误的输入推断出合理的输入
一个软件可以正确的运行在不同环境下
一个软件能够检测出自己内部设计或者编码错误,并得到正确的结果
健壮性与稳定性
健壮性与稳定性是特定软件自身的要求.
健壮性与稳定性是软件处理的一部分
- 软件架构的健壮性和稳定性是该软件规划时所确定的目标
- 若软件的实现未达到原定目标,则该软件的健壮性和稳定性不够或者不好.
架构质量的衡量
- 1.扩展性
- 2.维护性
- 3.可管理
- 4.高可用(故障修复,容灾,降级,熔断)
日常开放过程中的架构质量
-
理解难度
-
接入依赖的成本
提高扩展性和维护性
- 崩溃率和错误率的指标
- 开发效率,便于开发设计
- 错误上报与信息收集功能
正确的选择是良好的开端-架构前期准备
架构师分类
- 系统架构师
- 应用架构师
- 业务架构师
系统架构师(技术追求)
-
从系统的维度,负责整体系统的架构设计
-
主要是基础服务和各个系统间协调,着眼全局
-
比如关注负载, 可靠性,伸缩,扩展,整体项目切分,缓存应用等
方面的基础架构设计.
应用架构师(**并存,**业务更好实现,数据更好交互,设计易于扩展,对业务系统的流转做架构设计)
- 应用程序维度,负责某个应用的技术架构, 主要偏向于业务系统
- 关注理解业务,梳理模型, 设计模式,接口,数据交换等方面.
业务架构师
-
从业务流程的维度,关注某一个行业, 业务领域分析, 获取领域模型,最终获得系统的模型
-
也可以叫业务领域专家,行业专家,产品咨询师,资深顾问.
技术前期准备
技术选型:技术氛围,发展规模,未来发展趋势,与当前团队的契合度,执行成本,
维护成本与迁移成本,执行效率等方面内容的调研
充分调研每一项技术可能带来的利与弊.
最大程度上预测架构设计中的缺陷,以防止问题的发生.
技术优化
- 在架构发展过程中,可能会存在一些有悖于当前架构设计的实现,造成了架构发展阻塞,所以需要进行架构优化,
使得架构设计的适应性更高.
实时改进:改进实现,保证功能不去阻塞,更好获取状态
技术优化性
架构优化
代码集中一个文件,冗余,不易于查错, 将功能进行划分
利用差错优化
架构不是一蹴而就,在业务发展过程中,架构也在不断演进
v1.0,v2.0,v3.0
对架构设计进行实时调优, 使得架构优化成为常态化.
通过不断的调整架构实现,改进初始架构中设计的不足, 补足短板, 是设计不足导致,易于维护与扩展
总结:
架构师的分类,关注的技术点,架构的早期准备,架构实现过程, 技术优化是长期准备的过程.架构优化成为常态化, 不足架构设计的不足