7、软件架构特性解析与实践

软件架构特性解析与实践

1. 软件架构的模糊性与通用语言

在软件架构领域，一个长期困扰架构师的问题是众多关键概念缺乏清晰定义，甚至软件架构活动本身也是如此。这导致不同公司对常见事物定义各自的术语，进而在行业内造成混乱，架构师要么使用晦涩难懂的术语，要么用相同术语表达截然不同的含义。虽然我们无法为软件开发界强制推行一套标准术语，但可以借鉴领域驱动设计的建议，在团队内部建立并使用通用语言，以减少因术语导致的误解。

2. 架构特性的权衡与“次优架构”

应用程序通常只能支持部分架构特性，原因主要有两点。其一，每个支持的特性都需要设计工作和可能的结构支持；其二，各架构特性之间相互影响。例如，提升安全性往往会对性能产生负面影响，因为应用程序需要进行更多的实时加密、隐藏机密信息的间接操作等，这些都可能降低性能。

可以用一个比喻来理解这种相互关联性：飞行员学习驾驶直升机时常常面临挑战，因为直升机需要双手和双脚分别控制，而且一个控制动作的改变会影响其他动作。因此，驾驶直升机是一种平衡操作，这很好地描述了选择架构特性时的权衡过程。架构师设计支持的每个架构特性都可能使整体设计变得复杂。

所以，架构师很少能设计出一个能使所有架构特性都达到最优的系统。更多时候，决策需要在多个相互竞争的关注点之间进行权衡。不要追求“最佳架构”，而应追求“次优架构”。过多的架构特性会导致设计出试图解决所有业务问题的通用解决方案，但这种架构往往难以奏效，因为设计会变得难以管理。

这意味着架构师应尽可能设计迭代式的架构。如果能更轻松地对架构进行更改，就不必在首次尝试时就追求绝对正确的设计。敏捷软件开发的一个重要经验是迭代的价值，这在软件开发的各个层面，包括架构设计中