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

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

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

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

二、可否采用整洁架构

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

三、交汇数据流

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

四、数据流的分割

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

五、小结

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

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

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

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

• 仔细权衡成本，哪里需要设计架构边界，以及这些地方需要的是完整的边界还是不完全的边界，还是可以忽略的边界；
• 不是一次性的决定，不能再项目开始时就决定好哪里需要设计边界，哪里不需要；
• 必须持续观察系统的演进，时刻注意哪里可能需要设计边界，然后仔细观察这些地方会由于不存在边界而出现哪些问题。