读《程序员必读之软件架构》

software architecture for developers

最近读了《程序员必读之软件架构》, 感觉大部分内容比较口水话,或者是我还领悟不到精髓。

不过书中还是提供一些比较有用的信息。比如在敏捷开发下大部分团队不再使用UML而采用简单的草图,

draft architecture

但是大部分草图不像UML那么规范化,不容易读懂。平常在画程序功能图或者说架构图的时候,总觉得无法
表述清楚整个系统的运行情况,看完书后发现是因为自己将不同层次的内容混杂在一起。为了表述清楚系统如何
构成,可以通过绘制多个不同层次的图来达到目的。

语境图

主要回答以下问题:

  1. 构建的系统是什么
  2. 谁会使用它
  3. 如何已有系统交互

容器图

容器图中是否容器的判断标准是:程序是否是单独进程运作。比如Web服务器和数据库服务器就是
单独的容器。容器也就是逻辑上可执行的文件或过程。

容器图主要回答以下问题:

  1. 软件系统的整体形态是什么样
  2. 采用的技术决策是什么
  3. 职责是如何分布的
  4. 容器之间如何交流
  5. 开发者在哪里写代码

组件图

组件图是对容器的剖析,帮助了解容器内部

主要回答以下问题:

  1. 系统由哪些组件/服务组成
  2. 在高层次上,系统如何工作是否清晰
  3. 所有组件/服务都驻留在一个容器吗

上面的图但凡包含各组成部分之间交互的,都需要规范化交互的类型的表示方法,比如数据流
怎么表示,模块依赖怎么表示,重要和非重要怎么表示等。

因此在绘图时,着重从下面几个属性出发来区分元素

  • 形状(方形、菱形….)
  • 线条(直线、虚线….,包括箭头)
  • 颜色
  • 边框(虚线、实线、双实线…)
  • 缩略语(元素简单的描述)

另外,最后讲到架构师除了关注功能需求外,还要思考一些非公能性需求:

  • 性能
  • 可伸缩性,主要从业务增长上衡量
  • 可用性,可接受的故障时间
  • 故障转移
  • 安全性,诸如权限
  • 审计,考虑记录一些关键用户操作的审计日志
  • 容错和恢复
  • 国际化和本地化
  • 监测和管理
  • 数据保存和归档
  • 互操作性,主要是和其他系统的交互

结语

了解一个系统应该怎么思考设计,让自己的设计能力提升一些