Question

软件存在于现实世界的语境中，而现实世界有约束。这一部分可以让你说明这些约束，这样你工作在约束以内就很清楚，它们如何影响你的架构决策也很明显。

意图

约束通常是强加于你的，但不一定是“坏的”，因为减少可用的选项数目常常会让你的工作——设计软件——更容易。这一部分可以让你明确地总结工作中受到的约束，以及已经为你作出的决策。

结构

就像质量属性，直接列出并简要总结已知的约束就行了。约束的例子包括：

时间、预算和资源；

允许使用的技术清单和技术约束；

目标部属平台；

已有系统和继承标准；

局部标准（比如开发、编码等）；

公共标准（比如，HTTP、SOAP、XML、XML结构、WSDL等）；

标准协议；

标准消息格式；

软件开发团队的规模；

软件开发团队的技能配置；

所构建软件的本质（比如战术或战略）；

政治约束；

内部知识产权的使用；

等等

如果约束确实有影响，就值得总结（比如，它们是什么、为什么要强加它们，是谁强加的），说明它们对你的架构有多重要。

动机

约束具有大规模影响架构的能力，特别是如果它们限制了可用于构建解决方案的技术。用文档记录下来，让你不必在未来回答关于为什么好像做了一些奇怪决定的问题。

受众

参与软件开发过程的每一个人，因为有些约束是技术性的，有些不是。

是否必须

是，所有软件指南都应该包含对约束的总结，因为它们通常以某种方式塑造了最终的软件架构。任何时候明确做出这些约束都是值得的，即使在有非常著名的约束集（比如，“我们所有的软件都是用ASP.NET访问SQL服务器数据库”）的环境中，因为约束会随着时间不断变化。