关于golang:架构整洁之道读书笔记-Clean-Aechitecture

    最近感觉网络上贩卖的焦虑切实是太多了, 其实以前也多多少少有这种感觉, 最近尤为重大, 可能也和开年后工作强度变大无关吧, 搞的身心比拟疲乏. 一些专业性比拟强的书也看不进去了, 拿起来之前没有看完的 Bob 大叔整洁系列的书缓缓看完了, 不得不说, 看书的确是一种比拟好的降压形式, 本篇文章次要记录一些书中的内容.

1) 介绍

    这本书为 Bob 大叔 (Robert C. Martin) 的驰名作品, 同系列的还有《代码整洁之道》, 都是经典作品, 值得浏览. 该书零碎的分析了架构设计的缘起, 外延以及利用场景.

• 第 1 局部形容架构设计的 重点 与模式
• 第 2~4 局部次要为 编程范式
• 第 5 局部为架构设计中的 组件边界 、 设计模式 等
• 第 6 局部为 实现细节
• 附录局部为作者的一些亲身经历等

    这个系列其实还有一本作品 –《代码整洁之道 – 程序员的职业素养》(The Clean Coder – A code of Conduct For Professional Programmers), 次要讲述作者的一些经验, 如何走上编程路线等, 同样举荐浏览. 读完不禁感叹, 大神的成长之路也不是一帆风顺的, 其中教训尽管不能说肯定实用于当初, 然而齐全值得咱们学习和借鉴的.

<!–truncate–>

2) 设计与架构到底是什么

1) 指标

软件架构的终极目标

用最小的人力老本满足构建和保护该零碎的需要;

2) 两个价值维度

能够从 两个价值维度 来形容

• 行为价值

是最直观的价值维度, 程序员的工作就是让机器依照某种指定形式运行, 给零碎的使用者发明或者进步利润.

大部分程序员认为这就是他们的全副工作. 他们的工作是且仅是:

依照需要文档编写代码, 并且修复任何 Bug.

这是大错特错的.

• 架构价值

软件系统的第二个价值维度, 是指软件的灵活性, 软件必须放弃灵便.

从零碎相干方的角度来看, 他们提出的一系列的变更需要领域都是相似的, 因而老本也应该是固定的.

然而从研发者角度来看, 零碎用户继续一直的变更需要就像是要求他们不停的用一堆不同形态的拼图块, 拼出一个新的形态, 整个过程将会越来越艰难. 问题的本源就是零碎的架构设计

3) 哪个价值维度更重要

    不同的人给出的答案会不一样. 业务部门感觉零碎失常工作很重要, 很多开发人员也追随采取了这种态度, 然而 Bob 大叔认为这种态度是谬误的.

• 能够失常工作, 然而无奈批改. 那么当需要变更时, 它将无奈失常工作, 咱们也无奈批改, 因而价值为 0
• 无奈失常工作, 易于批改. 能够随着续期变动一直批改, 一直产生价值.

4) 艾森豪威尔矩阵

    重要的事件占据了后面两位, 开发人员和业务部门常常犯的独特谬误就是把第三优先级 不重要但紧急 的事件提到了第一优先级去做, 也就是说没有把 真正紧急且重要 和紧急然而不重要 的性能离开, 这个谬误导致了重要的事被忽略了, 重要的零碎架构问题让位给了不重要的零碎行为性能.

    然而研发人员还遗记了一点, 那就是业务部门本来就是没有能力评估零碎架构的重要水平的, 这原本就应该是研发人员本人的工作职责.

    如果漠视软件架构的价值, 零碎将会变得越来越难以保护, 终会有一条, 零碎将会变得无奈批改. 如果零碎变成了这个样子, 那么阐明软件开发团队没有和需求方做足够的抗争, 没有实现本人应尽的职责.

3) 编程范式

    编程范式指的是程序的编写模式, 与具体的编程语言关系较小, 这些范式会通知你应该在什么时候采纳什么样的代码构造. 直到明天, 咱们也一共只有三个编程范式, 而且将来简直不可能呈现新的.

    每个编程范式都从某一方面 限度 和标准 了程序员的能力, 这些范式次要是为了通知咱们不能做什么, 而不是能够做什么.

1) 结构化编程

结构化编程对程序控制权的间接转移进行了限度和标准

主张限度 goto 等无限度的跳转语句, 应用熟知的 if/then/else/do/while/until 等语句来进行替换

2) 面向对象编程

面向对象编程对程序控制权的间接转移进行了限度和标准

三大个性为 封装 、 继承 、 多态 , 波及到的概念还有 管制反转 (实现形式有 依赖注入), 古代代表语言有 java 等 …

3) 函数式编程

函数式编程对程序中的赋值进行了限度和标准

    从实践上来说, 函数式编程语言中应该是没有赋值语句的, 大部分函数式编程语言只容许在十分严格的条件下, 才能够更改某个变量的值.

当然下面说的只是一种思维, 理论使用起来必定还是有差异的, 古代代表语言有 golang 等 …

4) SOLID 设计准则

    通常来说, 想要构建一个好的软件系统, 应该从写整洁的代码开始 (能够看看 Bob 大叔的《代码整洁之道》). SOLID 设计准则 就是用来解决这样的问题, 通知咱们如何组织数据和函数等.

1) S – 繁多职责准则

    基于 康威定律 (Conway's Law) 的一个推论, 一个软件系统的最佳架构高度依赖于开发这个零碎组织的内部结构. 这样, 每个软件的模块都有且只有一个须要被扭转的准则.

康威定律: 软件架构可能反映出制作团队的组织架构

2) O – 开闭准则

    由 Bertrand Meyer 在 20 世纪 80 年代大力推广, 外围因素为: 如果软件系统要想更容易被扭转, 那么其设计就必须容许新增代码来批改零碎行为, 而非只能靠批改原来的代码.

3) L – 里氏替换准则

    由 Barbara Liskov 在 1988 年提出的一个子类型定义, 简而言之为: 如果要用可替换的组件来构建软件系统, 那么这些组件必须恪守同一个约定, 以便让这些组件能够互相替换.

4) I – 接口隔离准则

    次要告诫软件设计师应该再设计中防止不必要的依赖

5) D – 依赖反转准则

    该设计准则指出: 高层策略性的代码不应该依赖实现底层细节的代码, 恰恰相反, 那些实现底层细节的代码应该依赖高层策略性的代码

5) 软件架构

    Bob 大叔书中有个观点我集体十分认可. 首先, 软件架构师本身须要是程序员, 并且必须始终保持做一线程序员, 相对不要服从那些说应该让软件架构师从代码中解放出来以分心解决高阶问题的伪倡议. 如果不亲自接受因零碎设计而带来的麻烦, 就领会不到设计不佳所带来的的苦楚, 接着就会逐步迷失正确的设计方向.

软件系统的架构品质是由它的构建者所决定的, 软件架构这项工作的本质就是:

布局如何将零碎切分为组件, 并且安顿好组件之间的排列关系, 以及组件之间互相通信的形式.

蕴含以下方面:

• 开发(Development)

• 部署(Deployment)

• 运行(Operation)

• 保护(Maintenance)

6) 整洁架构

1) 一些根本的架构特点

• 六边形架构
• DCI 架构
• BCE 架构

根本特点:

• 独立于框架
• 可被测试
• 独立于 UI
• 独立于数据库
• 独立于任何内部机构

2) 整洁构建

    这是 Bob 大叔依据一般性架构特点总结进去的一个独立概念

• 依赖关系规定

    源码中的依赖关系规定必须只指向同心圆的内层, 即由底层机制指向高层策略

• 业务实体

    业务实体这一层封装的是整个零碎的要害业务逻辑, 一个业务实体既能够是一个带有办法的对象, 也能够是一组数据结构的汇合. 无论如何, 只有它能被零碎中的其它不同利用复用就能够.

• 用例

    通常蕴含的是 特定利用场景下 的业务逻辑, 这外面封装并实现了整个零碎的所有用例. 这些用例疏导了数据在业务实体之间的流入和流出, 并指挥着 业务实体 利用其中的要害业务逻辑来实现用例的设计指标

用例层应该与 业务实体 和内部因素 (比方数据库、UI、框架等) 隔离

• 接口适配器

    软件的接口适配器通常是一组 数据转换器, 转换成各层所须要的数据格式

• 框架与驱动程序

    最外层的 模型层 个别是由工具、数据库、Web 框架等组成的, 在这一层中, 咱们通常只须要编写一些与外部沟通的粘合性代码.

    框架与驱动程序层中蕴含了所有的实现细节. Web 是实现细节, 数据库也是实现细节, 将这些实现细节放在最外层, 这样他们就很难影响到其它层了.

• 只有四层吗

    只是为了阐明构造和依赖关系, 并不是示意只能有 4 层. 有可能会超过四层, 然而其中的依赖关系是不会扭转的.

    源码层面的依赖关系肯定要指向同心圆的内侧, 档次越往内, 其形象和策略的档次就越高, 其蕴含的高层策略就越多. 最内层的圆中蕴含的是最通用、最高层的策略, 最外层的圆蕴含的是最具体的细节

    感兴趣的同学还能够去看看当初大火的 DDD - 畛域驱动设计 (Domain Drive Design) 的思维, 未免能够找到一些共通之处.

7) 结束语

    心愿大家可能有所播种, 成为本人心中想成为的架构师.