微前端1：前置1 -- 软件设计原则与分层

软件设计原则

单一职责原则

• 永远不应该有多于一个原因来改变某个类。
• 理解：对于一个类而言，应该仅有一个引起它变化的原因。
• 应用：如果一个类拥有了两种职责，那就可以将这个类分成两个类。

开放封闭原则

• 软件实体扩展应该是开放的，但对于修改应该是封闭的。
• 理解：对扩展开放，对修改封闭。可以去扩展类，但不要去修改类。
• 应用：当需求有改动，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。

里式替换原则

• 理解：父类一定能够被子类替换。
• 应用：当对父类的引用改成子类时，应对程序没有任何影响。

接口隔离原则

• 一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。
• 理解：不要对外暴露没有实际意义的接口。用户不应该依赖它不需要的接口。
• 应用：当需要对外暴露接口时，如果是非必要对外提供，尽量删除。

依赖倒置原则

• 高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
• 理解：应该面向接口编程，不应该面向实现类编程。
• 并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。

最少知识原则

• 只与你最直接的对象交流。
• 理解：高内聚、低耦合。
• 应用：做系统设计时，尽量减小依赖关系。

六大设计原则 SOLID，有助于项目稳定性。

组合/聚合复用原则

• 当要扩展类的功能时，优先考虑使用组合，而不是继承。
• 该原则在23种经典设计模式中频繁使用。
• 如：代理模式、装饰模式、适配器模式、单例模式等。

无环依赖原则

• 当A模块依赖于B模块，B模块依赖于C模块，C模块依赖于A模块，此时将出现循环依赖。
• 在设计中避免出现该问题，可通过引入 "中介者模式" 解决。

共同封装原则

• 应该将易变的类放在同一个包里，将变化隔离出来。
• 该原则是 "开放-封闭原则" 的延伸。

共用重用原则

• 如果重用了包中的一个类，那么也就相当于重用了包中的所有类，我们要尽可能减小包的大小。

好莱坞原则

• Don't call me, I'll call you.
• "控制反转" （或称为 "依赖注入"）
• 不需要主动创建对象，而是由容器帮我们来创建并管理这些对象。

不要重复你自己

• 不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。

保持它简单与傻瓜

• 保持系统界面简洁，功能实用，操作方便。

高内聚与低耦合

• 模块内部需要做到内聚度高，模块之间需要做到耦合度低。

关注点分离

• 将一个复杂的问题分离为多个简单的问题，然后逐个解决。
• 难点：如何进行分离。

你不需要它

• 不要一开始就把系统设计得非常复杂，不要陷入 "过度设计" 的深渊。
• 让系统足够简单，而又不失扩展性。

软件设计分层

系统级架构

• 应用在整个系统内，如与后台服务如何通信，与第三方系统如何集成。
• 设计前端首要条件：了解前端系统与其他系统之间的关系，
• 关系包括：业务关系和协作机制。
• 设计后端：只需要规定与后台数据传递的机制。
• 包括：api 设计规则，访问授权的一个开放标准（OAuth）跳转 token 的验证，数据传递cookie等。
• 前端与后端的关系考虑的主要因素是：前后端分离的架构设计。
• 前后端分离架构其实是如何实施技术决策，用户鉴权、API接口管理和设计、API文档管理、Mock的使用、BFF（服务于前端的后端，nodejs），是否需要服务端渲染等。

微前端

• 在一个系统内微前端是应用间的架构方案。
• 在多个应用之间，微前端则是一种系统间等架构方案。
• 微前端是将多个前端应用以某种形式结合在一起进行应用。
• 旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题。
• 单实例：即同一时刻，只有一个子应用被展示，子应用具备一个完整的应用生命周期。
• 多实例：同一时刻可展示多个子应用。通常基于 url 的变化来做子应用的切换。
• 通常使用 Web Components 方案来做子应用封装，子应用更像是一个业务组件而不是应用。

应用级架构

• 应用级架构可以看做是系统级架构的细化。
• 单个应用与其他外部应用的关系，微服务架构下多个应用的协作，数据交换等。
• 形式：脚手架、模式库、设计系统。

模块级架构

• 这部分内容是我们开始业务编码之前进行设计，我们称为迭代。

代码级架构

• 规范与原则。
• 实操：开发流程、代码质量以及改善、规范而非默契。
• 注意：在开发中，要注意可维护性。简单的代码可维护性高，越是写的抽象的代码越难维护。

如何保证架构的质量

系统的稳定性

• 定义：当一个实际的系统处于一个平衡的状态时，如果受到外来作用的影响时，系统经过一个过渡过程仍然能够回到原来的平衡状态，我们称这个系统就是稳定的，否则称系统不稳定。
• 架构设计的基石。
• 可以更好的实现自我修复。

系统的健壮性

• 定义：计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机，不崩溃，就是该软件健壮性的具体表现。
• 解释：一个系统容错能力强，运行不易被干扰，安全性好。

系统的健壮性的度量标准

• 一个软件可以从错误的输入推断出正确合理的输入。
• 一个软件可以正确的运行在不同环境下。
• 一个软件可以检测自己内部的设计或者编码错误，并得到正确的结果。

架构质量的衡量

• 拓展性
• 维护性
• 可管理
• 高可用（故障修复，容灾，降级，熔断）

1