Question

作为软件开发者，我们创建的每一件东西都存在于现实世界中，而现实世界就有约束。像质量属性一样，约束可以驱动、塑造和影响软件系统的架构。任职的组织或是工作的环境，都会将约束强加于你。约束的形态和大小不尽相同。

时间和预算的约束

时间和预算可能是大多数软件开发者都熟悉的约束，因为这两者常常都不够。

技术约束

构建软件的时候，我们经常碰到一些技术相关的约束，特别是在大型组织里。

批准的技术清单：许多大型组织都有一个允许用于构建软件系统的技术清单，目的是限制组织必须支持，运行，维护和购买许可证的技术。如果你想使用任何不在清单上的技术，通常有一个漫长的例外流程，需要提出正式的申请。然而，我仍看到有团队为了能在Java项目中使用Groovy或者Scala而偷偷引入额外的JAR文件！

现有系统的互操作性：在大多数组织中，你的软件需要整合已有的系统，而实现整合的手段往往非常有限。除此之外，就是别的系统需要和你构建的系统整合。在这些情况下，你可能会发现，组织性的约束规定了你可以用于整合的协议和技术。一些我合作过的投资银行就有他们自己内部用来在软件系统间交换交易信息的XML结构。我可不会用“简洁”和“易用”来描述它们！

目标部署平台：构建一个全新的软件系统时，目标部署平台通常是影响技术决策的主要因素之一。这包括嵌入式设备、微软的Windows或Linux服务器的可用性，以及云。是的，即使这个我们称为云的神奇的东西，也有约束。举个例子，每个“平台即服务”（PaaS）提供的都不同，对某些东西，比如本地磁盘操作，你的软件能做什么，不能做什么，大多数都有限制。如果你不明白这些约束，部署时，陪伴你的很可能是焦虑的返工。

技术成熟度：有些组织乐于采用有风险的尖端技术，拥抱这种进步带来的风险。其他组织本质上则保守得多。

开放源代码：同样的，有些组织仍然不喜欢使用开源项目，除非它跟IBM或微软这样的名字扯上关系。我曾经在一个高街银行1的项目中工作，该银行拒绝使用开源项目，却乐于使用来自一个非常著名的技术品牌的Web服务器。那是伪装过的开源Apache Web服务器。这样的组织在遇到问题的时候就喜欢冲人大喊大叫。开源许可证的混乱也阻碍了一些组织完全采用开源项目。如果你曾试图解释GPL和LGPL的区别，可能已经目睹过这种情况。

供应商“关系”：就像生活中的很多事情，不是你知道什么，而是你认识谁。很多合作关系仍然是供应商请CTO（Chief Technology Officer，首席技术官）吃喝玩乐，在高尔夫球场上“达成”的。如果你曾为大型组织工作，也好奇为什么你的团队被迫使用一些明显不合格的东西，原因可能就是这个！

过去的失败：2000年前后，我带着用Java RMI——一种允许通过Java虚拟机进行远程方法调用的技术——构建解决方案的提案走进一家银行。我遇到了很大的阻力，因为这家银行已经“尝试过它，不管用”。那个设计到此为止，任何讨论都没能改变他们的主意。由于过去的失败，Java RMI在这样的环境下被封杀。最终我们转而构建了一个框架，通过HTTP将序列化的Java对象传给一群Java Servlets（变相重新发明轮子）。

内部知识产权：当你需要找到一个库或框架来解决所面临的问题，很可能已经有符合你需要的开源或商业产品。然而对有些人来说这还不够好，你必须使用组织自己内部的日志库、持久化框架或通信基础设施服务。这种情况并不罕见，不管它们是否真能正常工作。最近我听说一个组织构建了自己的CORBA2实现。

1一般而言，各大城市都有一条或者数条商业大街（high street），街上遍布各种银行、商店、邮局、警察局、超市、快餐店等。在英国，位于这类街上的银行被称为“高街银行”（high street bank），主要是提供便民服务，也称为“零售银行”。因此这类银行允许的贷款额度就比较小。——译者注

2Common Object Request Broker Architecture，通用对象请求代理架构，是由OMG（Object Management Group，对象管理组织）定义的标准，旨在促进部署于不同平台的系统间通信。——译者注

人员约束

更常见的是，开发软件可用的技术和方法受限于你周围的人。比如下面这些。

你的开发团队有多大？

他们有什么技能？

如果你的开发团队需要扩展的话，能有多快？

如果需要的话，你能够提供培训、咨询和专家吗？

如果在交付后转交你的软件，接手的维护团队拥有和你的开发团队相同的技能吗？

如果你让一个Java团队构建一个微软.NET解决方案，相当于给他们当头一棒。因此，当你架构一个软件系统时，也要把人考虑进来。

组织约束

你要知道，有时候还有其他约束，包括下面这两个。

软件系统是战术或战略实施的一部分吗？这个问题的答案会影响约束的增减。

组织政治有时能阻碍你实现真正想要的解决方案。

约束都是不好的吗

被强加的约束通常是“坏”的，但往往是出于好的理由。比如，大型组织不愿意支持和维护天底下所有技术，就试图限制最终用于生产的技术。一方面，这会降低创造力；但另一方面，它也剔除了你可能面对的大量潜在选项。软件架构也事关引入约束，在一个代码库里面你到底想要多少个日志库或持久化库？

约束可以划分优先级

最后一点，值得记住的是，约束可以划分优先级。就像功能需求，有些约束比其他的更重要，利用好这一点。我在培训中用作案例学习的金融风险系统就是基于我为伦敦的一个咨询公司工作期间的真实项目。一个投资银行找到我们，说他们需要一个金融风险系统，背后的基本前提是，由于监管原因，银行需要有一个风险系统才能进入一个新的细分市场。

经过几次售前会议和专题研讨，对于他们的需求以及在工作中需要面对的约束，我们有了一个比较好的想法。主要的约束之一是包括典型的重量级Java EE栈在内的批准的技术清单，另一个是严格的时间约束。

在准备财务提案时，我们大致说了这样的话，“是的，我们有信心在最后期限前交付系统，但为了加快项目，我们要使用一些不在你们的批准技术清单上的技术”。我们的提案被接受了。在这种情况下，时间约束被看作比只使用批准技术清单上的技术重要得多，实际上，我们会划分约束的优先级。约束通常是你需要绕过的障碍，但有时候也能相互权衡。

倾听约束

每一个软件系统都要屈从于一个或多个约束，软件架构角色的一部分就是找出这些约束，搞清楚它们为什么会被强加进来，让它们帮助你塑造软件架构。做不好这件事，搞不好会出大事。