《架构整洁之道》之层次与边界

人们通常习惯于将系统分成三个组件:UI、业务逻辑和数据库。对于一些简单系统来说,的确可以这样,但稍复杂一些系统的组件就远远不止三个了。

一、基于文本的冒险游戏:Hunt The Wumpus

  • UI与游戏业务逻辑解耦;
  • 游戏版本可以在不同地区适用不同语言;
  • 游戏的业务逻辑与UI之间应该采用一种与自然语言无关的API进行通信。

二、可否采用整洁架构

  • 语言并不是UI变更的唯一方向;
  • 构造一个API让语言部分与通信隔离开;
  • API的定义和维护都是由使用方负责,而非实现方;
  • 数据流分成两路,左侧的数据流关注如何与用户通信,而右侧的数据流关注的是数据持久化。

三、交汇数据流

随着系统的复杂化,组件在架构中自然会分裂出多条数据流。

四、数据流的分割

数据流全部汇聚到一个组件上,但现实情况往往不如人所愿。

五、小结

作为架构师,我们必须要小心审视究竟在什么地方才需要设计架构边界。另外,我们还必须弄清楚完全实现这些边界将会带来多大的成本。

同时,我们也必须要了解如果事先忽略了这些边界,后续再添加会有多么困难,哪怕有覆盖广泛的测试,严加小心的重构也于事无补。

所以作为架构师,我们应该怎么办?这个问题恐怕没有答案。一方面,就像一些很聪明的人多年来一直告诉我们的那样,不应该将未来的需求抽象化。这就是YAGNI原则:臆想的需求事实上往往是不存在的。这是一句饱含智慧的建议,因为过度的工程设计往往比工程设计不足还要糟糕。但另一方面,如果我们发现自己在某个位置确实需要设置一个架构边界,却又没有事先准备的时候,再添加边界所需要的成本和风险往往是很高的。

现实就是如此。作为软件架构师,我们必须有一点未卜先知的能力。可归纳为如下:

  • 仔细权衡成本,哪里需要设计架构边界,以及这些地方需要的是完整的边界还是不完全的边界,还是可以忽略的边界;
  • 不是一次性的决定,不能再项目开始时就决定好哪里需要设计边界,哪里不需要;
  • 必须持续观察系统的演进,时刻注意哪里可能需要设计边界,然后仔细观察这些地方会由于不存在边界而出现哪些问题。
文章目录
  1. 1. 一、基于文本的冒险游戏:Hunt The Wumpus
  2. 2. 二、可否采用整洁架构
  3. 3. 三、交汇数据流
  4. 4. 四、数据流的分割
  5. 5. 五、小结