7、软件架构：模糊性、权衡与特征识别

软件架构：模糊性、权衡与特征识别

1. 软件架构中的诸多模糊性

在软件架构领域，架构师们一直面临着一个令人沮丧的问题，那就是许多关键事物缺乏清晰的定义，甚至软件架构活动本身也是如此。这导致不同公司会为常见事物定义自己的术语，进而在整个行业内造成混乱。架构师们要么使用晦涩难懂的术语，要么更糟糕的是，用相同的术语表达截然不同的含义。

尽管我们希望为软件开发行业制定一套标准术语，但这是不现实的。不过，我们可以借鉴领域驱动设计的建议，在团队内部建立并使用通用语言，以减少因术语理解不同而产生的误解。

2. 权衡与“最不坏”架构

由于各种原因，应用程序通常只能支持我们所列的部分架构特性。一方面，每个受支持的特性都需要设计工作，可能还需要结构上的支持；另一方面，每个架构特性往往会对其他特性产生影响。

例如，如果架构师想要提高安全性，几乎肯定会对性能产生负面影响。因为应用程序需要进行更多的实时加密、隐藏机密信息的间接操作等，这些活动可能会降低性能。

这就像飞行员学习驾驶直升机一样，直升机的操作需要双手和双脚分别控制，改变一个控制动作会影响其他动作。因此，驾驶直升机是一种平衡的艺术，这很好地描述了选择架构特性时的权衡过程。架构师为每个特性提供支持时，都可能使整体设计变得复杂。

所以，架构师很少能设计出一个能最大化所有架构特性的系统。更多时候，决策需要在几个相互竞争的因素之间进行权衡。我们不应追求“最佳架构”，而应追求“最不坏的架构”。过多的架构特性会导致设计出试图解决所有业务问题的通用解决方案，但这种架构往往难以实施，因为设计会变得难以管理。

这意味着架构师应尽可能采用迭代的方式进行架构设计。如