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

1) 介绍

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

重点模式编程范式组件边界设计模式实现细节

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

<!–truncate–>

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

1) 指标

软件架构的终极目标

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

2) 两个价值维度

两个价值维度

  • 行为价值

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

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

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

这是大错特错的.

  • 架构价值

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

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

问题的本源就是零碎的架构设计

3) 哪个价值维度更重要

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

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

4) 艾森豪威尔矩阵

重要且紧急 重要不紧急
不重要但紧急 不重要且不紧急 
不重要但紧急真正紧急且重要紧急然而不重要
这原本就应该是研发人员本人的工作职责

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

3) 编程范式

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

限度标准

1) 结构化编程

结构化编程对程序控制权的间接转移进行了限度和标准
gotoif/then/else/do/while/until

2) 面向对象编程

面向对象编程对程序控制权的间接转移进行了限度和标准
封装继承多态管制反转依赖注入

3) 函数式编程

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

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

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

4) SOLID 设计准则

SOLID设计准则

1) S – 繁多职责准则

康威定律(Conway's Law)

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

2) O – 开闭准则

Bertrand Meyer

3) L – 里氏替换准则

Barbara Liskov

4) I – 接口隔离准则

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

5) D – 依赖反转准则

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

5) 软件架构

软件架构师本身须要是程序员, 并且必须始终保持做一线程序员, 相对不要服从那些说应该让软件架构师从代码中解放出来以分心解决高阶问题的伪倡议

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

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

蕴含以下方面:

  • 开发(Development)

  • 部署(Deployment)

  • 运行(Operation)

  • 保护(Maintenance)

6) 整洁架构

1) 一些根本的架构特点

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

根本特点:

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

2) 整洁构建

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

  • 依赖关系规定

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

  • 业务实体

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

  • 用例
特定利用场景下业务实体
业务实体内部因素
  • 接口适配器
数据转换器
  • 框架与驱动程序
模型层

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

  • 只有四层吗

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

最内层的圆中蕴含的是最通用、最高层的策略, 最外层的圆蕴含的是最具体的细节
DDD -畛域驱动设计

7) 结束语

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