Question

我举办的培训班经常要求学员分成小组设计一个简单的金融风险系统。当问起为什么他们的图表不包含任何技术决策，我会听到下面这些常见的回答。

“[风险系统]解决方案很简单，可以用任何技术构建。”

“我们不想强迫开发者使用一种解决方案。”

“那是实现细节。”

“我们遵循‘最后责任时刻’原则。”

我坚信，架构图应该包括技术的选择，但这里有另外一个问题，为什么人们不乐意做技术决策。说“它可以用任何技术构建”并不意味着应该如此。原因如下。

你有复杂的非功能需求吗

确实，大多数软件系统都可以用几乎任何技术构建，Java、.NET、Ruby、Python、PHP，等等。看看大多数软件系统的数据存储需求，也会发现几乎所有的关系型数据库都能完成任务。大多数软件系统在非功能特性方面的要求都不高，因此任何主流技术都差不多能满足。

但是，如果你有复杂的非功能需求，比如高性能或可伸缩性，那会怎样？事情很可能开始变得棘手，你必须搞清楚你的技术（和架构）选择是否会管用。如果你不考虑非功能需求，你的软件系统就可能无法满足目标。

你有约束吗

对于构建软件可采用的技术和的可选的技能（人），很多组织都有约束。有些甚至断定软件应该购买或定制，而非自己构建。约束能（且会）影响你能给出的软件架构。可以用各种手段挑战约束，但不能忽视，否则就会有交付一个无法与组织已有的IT环境集成的软件系统的风险。

你有一致性吗

想象你在构建一个把数据存储到关系型数据库的软件系统。在实现功能时，开发者个人如何从数据库检索数据和向其存入数据重要吗？我见过一个Java系统，同一个代码库中采用了多个数据访问技术/框架；还见过一个SharePoint系统，各个组件的配置方式不尽相同。有时候，发生这种事情是因为代码库随着时间演变，方法也在变化，但通常只是开发团队每个人完全自由选择自己最熟悉的任何技术/框架/方法带来的副作用。

人们经常问我“选择哪个日志框架是否真的很重要”，如果你想让开发团队里每个人都使用同一个日志框架，那么是很重要。有些人乐意允许开发团队里任何人下载和使用任何他们想要的开源库。另一些则意识到如果不加以检查，就会导致问题。我不是说要扼杀创新，但你的代码库真的应该只有一个日志、依赖注入或对象关系映射框架。

缺乏一致性的方法会导致代码库难以理解、维护和增强。增加单独可移动部件的数量也会让部署、运营和支持变得复杂。

推迟与解耦

有必要简单谈谈推迟技术决策和等到“最后责任时刻”才做出决策。让我们想象一下，你在设计一个没有任何特别繁重的非功能需求或约束的软件系统。你选择什么技术重要吗？一个好的架构难道不应该容许你日后改变主意吗？

举个例子，很多人会说，你用哪个关系型数据库真的不重要，特别是如果你用一个对象关系映射层将代码与特定的数据库实现解耦，比如Hibernate、Entity Framework或者ActiveRecord。如果你没有任何重要的非功能需求或约束，并且确实认为所有的关系型数据库都是相等的，那么你用哪一个可能不重要。是的，你可以在代码中解耦数据库，推迟技术决策。但是别忘了，当数据库的选择不再是重要决策，ORM的选择就是了。你可以通过引入另一个抽象层，在代码中解耦ORM，但这里又做了一个软件系统结构的重要决策。

解耦是很好的方法，原因很多，而且它使技术决策得以推迟。当然，这并不意味着你应该推迟决策，特别是由于非功能需求和约束的存在相关的原因。

每个决策都是权衡

这又回到一个事实，任何技术都有其优缺点，作为可交换的商品，并不一定有不同的选项。对于通常被看作是商业化的技术，关系型数据库和Web应用程序框架是两个典型的例子。很多云服务提供商也是如此，即使他们有各自关于部署、监测、管理、成本、持续磁盘访问等方面的权衡。

一天结束时，不论是否与性能、可伸缩性、可维护性、找到有合适经验的人的能力等方面相关，你做出的每一个技术决策都有权衡。理解技术选择也能协助高层次的预测和计划，如果你需要明白是否能用给定的有限预算实现目标，这就很有用。

如果你不明白选择X技术而非Y的权衡，那就不应该做决策。设计软件系统的人要懂技术，这很重要。这就是为什么软件架构师应该是建造大师。

技术不只是一个“实现细节”，你做出的技术决策跟你分解、安排和设计软件系统的方式同等重要。推迟技术决策，后果自负。