分层架构是运用最为广泛的架构模式,几乎每个软件系统都需要经过层来隔离不同的关注点,以此应对不同需求的变化,使得这种变化可以独立进行;各个层、甚至同一层中的各个组件都会以不同速率发生变化。
这里所谓的“以不同速率发生变化”,其实就是引起变化的原因各有不同,这正好是单一职责原则(Single-Responsibility Principle,SRP)的体现。即“一个类应该只有一个引起它变化的原因”,换言之,如果有两个引起类变化的原因,就需要分离。
单一职责原则可以理解为架构原则,这时要考虑的就不是类,而是层次。例如网络七层协议是一个定义的非常好的、经典的分层架构,简单、易于学习理解,最终被广泛使用进而大大推动了网络通信的发展。
通常情况下,我们会把软件系统分为这几层:UI层、应用独有的业务逻辑、领域普通的业务逻辑、数据库等。
接下来,还有什么不同原因的变更呢?答案正是这些业务逻辑本身!在每一层内部,不同的业务场景发生变化的原因、频次也都不同,不同的场景我们分别定义为业务用例。由此,我们可以总结出一个模式:在将系统水平切分成多个分层的同时,按用例将其切分成多个垂直切片。这样做的好处就是对单个用例的修改并不会影响其他用例。
如果我们同时对支持这些用例的UI和数据库也进行了分组,那么每个用例使用各自的UI表现与数据库,这样就做到了自上而下的解耦。另一方面,有层次就有依赖。在OSI协议中,上层透明的依赖下层。但是在软件架构中,我们更强调“依赖抽象”。即组件A依赖B的功能,我们的做法是在A中定义其需要用到的接口,由B去实现对应接口能力,这样就做到了可插拔,将来我们可以把B替换为同样实现了接口能力的组件C而对系统不会造成影响。
二、整洁架构
分层架构中给人的感觉是每一层都同样重要,但如果我们把关注的重点放在领域层,同时把依赖关系按照业务由重到轻形成一个以领域层为中心的环,即演变为一种整洁的架构风格。这里不是说其他层不重要,仅仅是为了凸显承载了业务核心的领域能力。
整洁架构最主要原则是依赖原则,它定义了各层的依赖关系,越往里,依赖越低,代码级别越高。外圆代码依赖只能指向内圆,内圆不知道外圆的任何事情。一般来说,外圆的声明(包括方法、类、变量)不能被内圆引用。同样的,外圆使用的数据格式也不能被内圆使用。
整洁架构各层主要职能如下:
-
Entities:实现领域内核心业务逻辑,它封装了企业级的业务规则。一个Entity可以使一个带方法的对象,也可以是一个数据结构和方法集合。一般我们建议创建充血模式。
-
Use Cases:实现与用户操作相关的服务组合与编排,它包含了应用特有的业务规则,封装和实现了系统的所有用例。
-
Interface Adapters:它把适用于 Use Cases 和 entities 的数据转换为适用于外部服务的格式,或把外部的数据格式转换为适用于 Use Casess 和 entities 的格式。
最后
做任何事情都要用心,要非常关注细节。看起来不起眼的、繁琐的工作做透了会有意想不到的价值。
当然要想成为一个技术大牛也需要一定的思想格局,思想决定未来你要往哪个方向去走, 建议多看一些人生规划方面的书籍,多学习名人的思想格局,未来你的路会走的更远。
更多的技术点思维导图我已经做了一个整理,涵盖了当下互联网最流行99%的技术点,在这里我将这份导图分享出来,以及为金九银十准备的一整套面试体系,上到集合,下到分布式微服务
如何获得这套优质的资料呢?
d8IV-1628510067096)]
[外链图片转存中…(img-r22DTRoU-1628510067100)]
如何获得这套优质的资料呢?