一、软件系统设计的六项原则
1、单一职责原则（Single Responsibility Principle）
2、开闭原则（Open Closed Principle）
3、里氏替换原则（Liskov Substitution Principle）
4、迪米特法则（Law of Demeter），又叫“最少知道法则”
5、接口隔离原则（Interface Segregation Principle）
6、依赖倒置原则（Dependence Inversion Principle）
二、架构的种类
1.系统级架构，微前端可以算是系统级架构，也可以算是应用级架构
2.应用级架构：脚手架，模式库（ui库），设计系统
3.模块级架构：迭代
4.代码级架构：规范与原则
三、架构质量的衡量
1.拓展性
2.维护性
3.可管理
4.高可用（故障修复，容灾，降级，熔断）
四、日常开发过程中的架构质量
1.理解难度
2.接入依赖的成本
3.崩溃率和错误率的指标
4.开发效率
5.错误上报和信息收集等功能
五、架构的前期准备
架构师分类：
系统架构师：从系统的维度，负责整体系统的架构设计，纯技术架构
应用架构师：偏向业务的系统，关注理解业务
业务架构师：从业务流程的维度，关注某一个行业，所做的事情可能会脱离具体的代码开发，偏向于数据分析。
六、技术债务的产生
1.开发过程中因为时间紧迫而导致的实现不合理
2.开发过程中暂时没有想到更好的办法而去妥协进行的实现
3.架构设计前期没有考虑到的细节
4.不合理的交互设计，导致技术实现复杂
5.一些旧的功能在做的时候并没有详细的文档，并没有预留拓展接口，导致拓展困难，上线后问题剧增。技术债务累积过多产生的可能后果：
1.修复变重构，严重影响产出，
2.对旧功能需要不断进行兼容处理，严重影响开发速度
七、技术填补
1.项目拆分，代码解耦
2.必须有日志模块，操作日志，错误日志，业务日志等等
3.技术培训和传帮带能力
4.做好代码规范，编写好技术文档
5.不同工程师相互评审
6.用于发现系统中的技术债务等产品上线后，开发就没有那么紧啦，这个时间大家可以找个时间处理技术债务，一遍建立感情，一遍品味原来的代码
八、预防系统崩溃
系统崩溃属于严重的架构设计事故
崩溃预防：
1.抓取用户行为，获取用户操作链条
2.解决村存量的技术债务问题
3.减少新增问题
4.对脏数据进行兜底和检验
5.单元测试
6.崩溃预警
7.自动化测试
8.更广的灰度触达
9.性能优化体系当技术债务累积到一定的程度时，小软件可以考虑直接重构，快刀斩乱麻
九、重构流程
1.确定问题点，确定重构功能和范围
2.旧架构设计和逻辑梳理
3.稳定性保证
4.性能保证
5.需求过程中的冲突问题