这几年也做了一些应用架构，还有重构。教员的《实践论》曾说过，书本上的理论需要我们在实践中不断产生更多的感性认识，然后将感性认识整理，上升到理性认识，又继续再实践中校验，循环往复。最近刚好在面试，所以进行了整理，算是将理论与经验的总结。
整体纵向分离的架构、横向分离、架构模式、设计模式(原则/模式)之间的关系图。从宏观到微观，从整体到局部。
我简单描述下我个人的理解(不对的地方还望指出)： Android Google架构分层(UI层/业务层/数据层)和Clean Architecture 和 DDD 是一个更宏观/全局的，它是纵向分离的。
横向的是 组件化/微服务等，比如组件化，它是将 宏观里面的业务层的登录/注册组件化了，然后登录/注册业务模块里面，使用MVVM/MVI架构模式，主要还是数据流转的问题，比如你可以使用 lievedata + rxjava，也可以使用kotlin+flow。
然后设计模式的原则 是指导我们如何写出高质量的代码的心法，设计模式里面的 模式(比如工厂，单例)，是解决类与类之间的扩展，复用，解耦的招式。
纵向分层(Google官方架构/Clean Architecture等) + 横向分层(组件化/微服务等)：是 宏观/全局 的。纵向让整个应用的职责划分清晰；横向加强了解耦、提高协作效率，减少维护成本等。
架构模式(Architectural Patterns)是 中观/骨架 的，规范了某个模块的骨架、代码分层以及数据流向。
设计模式(Design Patterns) ：设计模式中的模式是 微观/局部 的，解决是的具体代码类与类之间的耦合、重用和扩展问题；设计模式中的原则是 底层基石，指导如何写出高质量代码。
设计模式原则
设计五大原则以SOLID（前五项首字母）为核心框架，共同实现 高内聚低耦合 的设计目标。
SOLID：单一职责原则(SRP)，开闭原则(OCP)、里氏替换原则(LSP)、接口隔离原则(ISP)、依赖倒置(反转)原则(DIP)。
这几个作为补充：迪米特法则(LOD)，DRY原则、KISS原则、YAGNI原则。
一句话概括：
SOLID+LOD 告诉你如何做对(规范类与类的关系)，KISS/YAGNI告诉你别做过头(避免过度设计)，DRY 别重复(消除冗余)。
有人会好奇，我之前也困扰，设计模式原则到底是六大原则？还是五大原则？
国内的很多书籍，都是六大原则，将LOD补上的。但按照国际正常来说，是五大原则(SOLID)。
问题
为何这么麻烦，不直接 UI 调用 Repository.
核心原因有几个层面：
- 直接原因：违反了分层架构的单向依赖
正确：UI → ViewModel → Repository → DataSource
❌ 错误：UI → Repository（跳层了）。
- 违反了设计模式的原则。
违反 SRP（单一职责），违反 DIP（依赖倒置）。
- 数据流无法管理，比如直接调用 login，然后呢？UI自己处理所有逻辑？？这样就变成和以前的MVC 没有本质区别了！！！脱离了ViewModel层， UI 状态管理 + 业务逻辑 + 线程调度，职责全部交给了UI层。
讨论
国内很多公司，前期只考虑开发进度，忽视代码质量，而且招聘的人员也参差不齐。 由于前期不考虑整体的应用架构，写代码也不符合代码规范，还有设计模式原则。 随着业务的需求增加，问题越来越多，维护成本增高。 最终的结局，就是重写，要么就是只能小范围重构。
我记得我早期重构的第一个项目就是开机向导，那个时候也不懂什么是重构，反正我就是想改了，因为我接手了，职业素养吧，还有程序员的追求，刚好最近也在学习设计模式，实践下。 代码写的是APage.java,BPage.java,CPage.java类似的命名。 然后代码充斥中各式各样的if...elseif...的机型判断。
后续再补充