【Spring Cloud 11】软件架构设计

如果我们同时对支持这些用例的UI和数据库也进行了分组，那么每个用例使用各自的UI表现与数据库，这样就做到了自上而下的解耦。另一方面，有层次就有依赖。在OSI协议中，上层透明的依赖下层。但是在软件架构中，我们更强调“依赖抽象”。即组件A依赖B的功能，我们的做法是在A中定义其需要用到的接口，由B去实现对应接口能力，这样就做到了可插拔，将来我们可以把B替换为同样实现了接口能力的组件C而对系统不会造成影响。

二、整洁架构

---

分层架构中给人的感觉是每一层都同样重要，但如果我们把关注的重点放在领域层，同时把依赖关系按照业务由重到轻形成一个以领域层为中心的环，即演变为一种整洁的架构风格。这里不是说其他层不重要，仅仅是为了凸显承载了业务核心的领域能力。

整洁架构最主要原则是依赖原则，它定义了各层的依赖关系，越往里，依赖越低，代码级别越高。外圆代码依赖只能指向内圆，内圆不知道外圆的任何事情。一般来说，外圆的声明（包括方法、类、变量）不能被内圆引用。同样的，外圆使用的数据格式也不能被内圆使用。

整洁架构各层主要职能如下：

1. Entities：实现领域内核心业务逻辑，它封装了企业级的业务规则。一个Entity可以使一个带方法的对象，也可以是一个数据结构和方法集合。一般我们建议创建充血模式。

2. Use Cases：实现与用户操作相关的服务组合与编排，它包含了应用特有的业务规则，封装和实现了系统的所有用例。

3. Interface Adapters：它把适用于 Use Cases 和 entities 的数据转换为适用于外部服务的格式，或把外部的数据格式转换为适用于 Use Casess 和 entities 的格式。

4. Frameworks and Drivers：这是实现所有前端业务细节的地方，UI，Tools，Frameworks 等以及数据库等基础设施。

三、六边形架构

---

我们把整洁架构的外部依赖按照其输入输出功能、资源类型进行整合。将存储、中间件、与其它系统的集成、http调用分别暴露一个端口。则会演变成下面的架构图。

系统能平等地被用户、其它程序、自动化测试或脚本驱动，也可以独立于其最终的运行时设备和数据库进行开发和测试。

最后

总而言之，面试官问来问去，问的那些Redis知识点也就这么多吧，复习的不够到位，知识点掌握不够熟练，所以面试才会卡壳。将这些Redis面试知识解析以及我整理的一些学习笔记分享出来给大家参考学习

还有更多学习笔记面试资料也分享如下：

找小编（vip1024c）领取

[外链图片转存中…(img-mjBsgwu1-1721722904048)]

找小编（vip1024c）领取