《架构整洁之道》摘录

原文转载自 「自由人的 BLOG」 (https://ifttl.com/reading-the-book-clean-architecture/)

预计阅读时间 0 分钟(共 0 个字, 0 张图片, 0 个链接)

花了一个多月读完了这本《架构整洁之道》,跟《代码整洁之道》《程序员的职业素养》算是一个 Clean 系列,每一本读来都很有启发。这本《架构整洁之道》有些地方看得还挺迷糊,值得一读再读。

概述、编程范式

设计与架构没有任何区别。一丁点区别都没有!软件架构的终极目标是,用最小的人力成本来满足构建和维护该系统的需求。

三种编程范式(结构化编程、面向对象编程和函数式编程)与软件架构的三大关注重点不谋而合:功能性、组件独立性以及数据管理。

面向对象编程到底是什么?对一个软件架构师来说,其含义应该是非常明确的:面向对象编程就是以多态为手段来对源代码中的依赖关系进行控制的能力,这种能力让软件架构师可以构建出某种插件式架构,让高层策略性组件与底层实现性组件相分离,底层组件可以被编译成插件,实现独立于高层组件的开发和部署。

软件架构师应该着力于将大部分处理逻辑都归于不可变组件中,可变状态组件的逻辑应该越少越好。

设计原则

组件构建原则

组件是软件的部署单元,是整个软件系统在部署过程中可以独立完成部署的最小实体。

与构建组件相关的三个基本原则

三个原则之间彼此存在着竞争关系。软件架构师的任务就是要在着三个原则中间进行取舍。一个项目在组件结构设计上的重心是根据该项目的开发时间和成熟度不断变动的,我们对组件结构的安排主要与项目开发的进度和它被使用的方式有关,与项目本身功能的关系其实很小。

组件耦合相关的原则

软件架构

软件架构师自身需要是程序员,并且必须一直坚持做一线程序员。

在软件系统的所有方面中,维护所需的成本是最高的。

所有的软件系统都是一组策略语句的集合。软件架构设计的工作重点之一就是,将这些策略彼此分离,然后将他们按照变更的方式进行重新分组。其中变更原因、时间和层次相同的策略应该被分到同一个组件中。优秀的架构师会小心地将软件的高层策略与其底层实现隔离开,让高层策略与实现细节脱钩,使其策略部分完全不需要关心底层细节,当然也不会对这些细节有任何形式的依赖。另外,优秀的架构师所设计的策略应该允许系统尽可能地推迟与实现细节相关的决策,越晚做决策越好。

层次、边界

一个软件系统可以被解耦成若干个水平分层——UI界面、应用独有的业务逻辑、领域普适的业务逻辑、数据库等。而系统的用例是系统水平分层的一个个垂直切片。

软件架构设计本身就是一门划分边界的艺术。边界的作用是将软件分割成各种元素,以便约束边界两侧之间的依赖关系。系统的核心业务逻辑必须和其他组件隔离,保持独立,而这些其他组件要么是可以去掉的,要么是有多种实现的。

业务逻辑应该保持纯净,不要掺杂用户界面或者所使用的数据库相关的东西。在理想情况下,这部分代码业务逻辑的代码应该是整个系统的核心,其他底层概念的实现应该以插件形式接入系统种。业务逻辑应该是系统中最独立、复用性最高的代码

软件架构师必须仔细权衡成本,决定哪里需要设计架构边界,以及这些地方需要的是完整的边界,还是不完全的边界,还是可以忽略的边界。我们的目标是找到设置边界的优势超过其成本的拐点,那就是实现该边界的最佳时机。

整洁架构

按照现有的一些优秀架构(六边形架构、DCI 架构、BCE 架构)设计出来的系统,通常都具有以下特点:

以几个同心圆画出来的整洁架构示意图,从里到外,各层分别是

实现细节

数据库并不是数据模型。数据库只是一款软件,是用来存取数据的工具。一个优秀的架构师是不会让实现细节污染整个系统架构的。数据本身很重要,但数据库系统仅仅是一个实现细节。

GUI 只是一个实现细节。而 Web 则是 GUI 的一种,所以也是一个实现细节。

框架并不等同于系统架构——尽管有些框架确实以此为目标。我们应该将框架作为架构最外圈的一个实现细节来使用,不要让它们进入内圈。不要让框架污染我们的核心代码,应该依据依赖关系原则,将它们当作核心代码的插件来管理。

相同的架构方式,可能有多种不同的代码组织方式,好的组织方式能够利用编译器来维护架构设计原则,而不依赖个人自律和编译过程之后的工具。

more_vert