一文读懂架构整洁之道，spring常见面试题总结超详细回答问题-CSDN博客

本文链接：https://blog.csdn.net/2401_84438893/article/details/138029813

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

REP：复用/发布等同原则
CCP：共同闭包原则
CRP：共同复用原则

REP是组件聚合总的指导原则，表示组件内的类和模块是彼此紧密相关的。CCP和CRP是对REP的补充，CCP可以看做是组件级别的单一职责原则（SRP）：由于相同原因修改，并且需要同时修改的东西放一起；不同原因修改，并且不同时修改的东西分开。CRP可以看做是组件级别的接口隔离原则（ISP）：不要依赖不需要的东西。

可以看出通过这三个原则构建的组件，拥有以下几个特点：

组件内的类和模块紧密相关，需求变更时通常需要同时修改；
需求变更时，需要进行的修改只涉及很少的组件甚至在一个组件内；
复用这个组件时，通常组件内的功能均是用户需要的，而不是有一些不相关的功能；

这里贴下书中的张力图：

项目的初期，更多关注的是维护性而牺牲复用性，随着项目逐渐成熟，项目重心会逐渐倾向于复用性。

**组件耦合

组件耦合方面的原则有以下几个：

ADP：无依赖环原则
SDP：稳定依赖原则
SAP：稳定抽象原则

组件间的依赖如果存在环，则维护性将大大降低，我们应该避免组件间的循环依赖。

组件间的依赖关系应该是指向更稳定的方向，每个组件的稳定性都低于其依赖的组件稳定性。组件越稳定，则其抽象程度需要更高；组件越不稳定，则其抽象程度需要更低，越具体。

有时候，可能会新引入一个引用，导致一个稳定的组件依赖了一个不稳定的组件，此时就可以使用依赖倒置原则（DIP）将依赖关系反转，保持稳定依赖。

分层与解耦

谈了组件相关的原则，现在来谈谈组件间的分层和隔离的方式。通过有效的分层手段，可以有效隔离不同功能的组件。

▐ 水平分层

得益于MVC模式的普及，水平分层在我们的系统中已经非常普及了，通常有以下几层：

表现层/UI层：负责系统的界面展示，通常包括Controller和VO等；
领域层/业务逻辑层：负责处理系统的业务逻辑，通常包括Service，Manager和DTO等；
数据层：负责与DB等底层数据存储介质通信，通常包括Mapper和DO等；

▐ 垂直分层

但是，仅仅做到水平分层是不够的。当业务逻辑比较复杂时，涉及的用例会非常多，这些用例之间的变更原因几乎肯定是不同的，所以还要进行垂直分层，将变更原因不一样的用例切分开。

例如，很多系统的修改操作和删除操作的变更原因和变更频率是不一样的，这时候可以考虑将修改和删除进行解耦。

不论是水平分层还是垂直分层，其核心目的都是将更新频率不同的代码给分开，放入不同的组件中。

▐ 解耦方式

分层后的解耦方式有多种：

源码层次：通过控制源代码模块间的依赖关系进行解耦，部署时仍然一起部署，适用于项目早期刚起步时；
部署层次：通过控制部署单元（例如jar包等）之间依赖进行解耦，当系统对部署和开发方面有更高的要求时，部分组件需要独立出去形成新的部署单元；
服务层次：通过将组件的依赖关系降低到数据结构级别，然后通过服务进行通信来解耦，当系统足够大的时候，就需要服务层次的解耦了；

但需要注意的是，不论通过哪种解耦方式进行代码的隔离，并不意味着这样就万事大吉，拥有良好可扩展和可维护性了。这也是Bob在《架构整洁之道》中提到的“横跨型变更”（虽然作者是在服务的这一章提出的，但我认为也适用于其他两种解耦层次）。

请看下面的出租车调度系统的服务架构图

图中可以看出，Taxi UI依赖 Taxi Finder查找符合条件的出租车，依赖Taxi Selector进行出租车调度。而Taxi Finder通过多个Taxi Supplier服务获取车辆信息，Taxi Selector依赖Taxi Dispatcher进行最终的派单。

各个组件都是服务化的。可以看到，各个组件都是具体的类，虽然各个组件隔离部署，但其实他们之间是强耦合的，并没有真正的解耦：加入现在出租车公司准备推出运送猫咪的服务，则所有的组件都需要进行更改，同时有些同学的更改方式就是在原有的类中增加if…else，这显然是不可取的。

正确的做法应该是在组件最初的设计中，就应该考虑抽象化和多态，如下图，使用策略模式或者模板方法进行解耦：

注意看我红框标出来的，除了服务间的隔离外，在组件内部其实也存在隔离，而这个的隔离更加重要。这也就是书中讲的：

服务边界并不能代表系统的架构边界，服务内部的组件边界才是。

架构

从代码和组件原则到组件分层和解耦，我们逐渐对系统底层的一些元素有了比较深入的了解，那么上层的架构到底是什么呢？

▐ 什么是架构

并没有非常明确的定义，这里引用书中的一些描述，大家应该有一些体会：

软件架构的实质就是规划如何将系统切分成组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式。

软件架构的终极目标是，用最小的人力成本满足构建和维护该系统的需求

需要指出的是，架构和框架并不是相同的东西：

架构一定是业务相关的，包含了业务属性，并且这个业务属性是系统的核心价值；
框架一般都是业务无关的，是我们编码实现架构的的工具，属于实现细节。

最初设计系统架构时，并不需要过多考虑使用什么框架，而更多的是关注自身业务。

此外，很多人可能对架构有些误解：设计那么多有什么用，代码不还照样得写？

是的，代码还得写，架构并不能让你不写代码了（有时可能还会让你多写代码）。但是，好的架构会让写代码变得更容易了。

容易不一定是体现在需要变更的代码量多少上，好的架构可以让你更快速的找出需要变更的范围，并且很容易的就修改掉——这对于一个运行维护了多年的系统尤为重要。大家可以回想下这样的场景是不是很熟悉：明明是一个看起来很正常很合理的需求，看起来变更范围也不大，但真的去撸代码时发现需要改的地方好多，甚至无从下手去改。这个时候可能就要去看看之前的架构设计是不是不够合理，有哪些需要优化改进的。

六边形架构

六边形架构，又名端口适配器架构（我更喜欢这个名字，因为六边形老让人感觉有六个什么东西跟它对应），DDD极力推崇该架构。系统的领域模型是系统最为重要的部分，而其他的诸如DB，UI，缓存，消息队列等等均通过适配器与领域层进行通信，也就是依赖关系是由外到内的（依赖倒置）。之前在商家规模化运营项目中也尝试过使用DDD来进行架构设计。