这篇文章先是出现在 IEEE Software 杂志上，IEEE Software 是一本提供严谨科技资讯的杂志。企业总是在可靠性和灵活性上面临挑战，IT 经理和技术领导者依赖 IT 专家们来提供高超的解决方案。
本文要点
- 架构原则确保设计决策在一定程度上能够满足需求
- 借助架构原则，可以在没有微管理的情况下建立边界和优先级
- 好的架构原则具有建设性，是合理的、良好定义的、可测试的，并且是重要的
- 偶尔会发生架构原则被破坏的情况，这时我们必须找出原因，因为这是一个改进架构原则的好时机
- 在架构原则的开发、捕捉和沟通上投入适当的时间有助于理论与实践之间的融合
人们经常会谈论系统的“架构设计原则”（或者直接叫“架构原则”）。不过在对“原则”进行清晰地定义之前，它所表示的意思还是很含糊的。对架构设计原则的角色和好处进行良好的定义，它将成为一个强有力的工具。
在这篇文章里，我将对架构设计原则做出定义，并探讨什么才是好的原则，以及如何在实际当中使用这些原则，从而能够从中获得价值。
原则的定义
我不打算对设计和架构这两者做任何刻意的区分，因为我认为在这里对它们进行区分没有任何意义。因此，我将会谈论一些设计原则，它们同时适用于细节层面和抽象层面。
牛津英语词典把原则描述为“一种基本的事实或主张，它是信念或行动的基础”，而设计是“一种计划或草稿，它展示了一栋建筑、一套服装或其它物体在成形之前的外观和功能或运行方式”。所以，我们可以把软件的设计原则定义为：
一种基本的事实或主张，它是决定软件系统运行方式的基础。
重点是，原则清晰地描述了意图，能够为设计工作提供指导。还有其它一些对设计原则的定义。在《Architecture Principles》[参考 1] 这本书里，Danny Greefhorst 和 Erik Proper 对设计原则给出了最具概括性的定义：
一个声明性的陈述，对人为事物的设计属性进行规范的定义，确保它们能够满足必要的需求
虽然这样的定义有些抽象，不过它至少澄清了设计原则的角色，它确保架构能够在一定程度上满足需求。
在进行抽象的定义之后，我们来看看真实的架构原则是什么样的。下面的表格展示了一个简单的架构原则，它是来自银行领域的一个真实案例。简单地说，这个原则：
- 提供了一个名字
- 给出了一个简洁清晰的描述
- 清楚地解释了原则背后的动机
- 定义了它所适用的领域（适用于特定类型的应用程序的消息服务，这些应用程序包含了特定的数据类型）
- 解释了这个原则的重要性，这样我们就可以选择合适的时机应用它
(点击放大图像)
对于设计过程来说，这样的输入是很有用处的，因为它强调了组织的优先级事项，并解释了原则的重要性，以及何时会变得重要。
架构原则的好处
架构原则概括了架构的功能：为系统设计清晰地定义必需的约束，而不必按照惯例定义所有的设计细节。我在之前的一个专栏文章里提到，架构就是要处理好系统组件之间的关系[参考2]。所以，架构原则有助于建立边界和优先级，不需要关心系统的每个组件是如何工作的。好的架构原则可以为我们带来如下的好处。
为设计决策提供基础
原则能够澄清优先级和约束，从而帮助人们做出可靠的设计决策。事实上，我发现架构原则可以让一些抽象的想法更易于理解，比如业务目标，同时它们能够帮助设计者做好技术决策。以后我会在新的专栏文章里深入探讨这个话题。
为决策、成本和时间提供依据
作为设计者，我们经常要面对一些情况，比如最终的计划总是比我们所预期的要占用更多的成本或时间，但我们却很难解释清楚为什么这个计划是正确的。有了清晰定义的原则，我们就能够解释这个问题。例如，系统必须支持高可用部署这个原则就可以解释为什么我们要为系统构建多节点运维能力，尽管这样做不是最省钱的方案。
增强合作、沟通和公共价值
跟其它架构元素一样，架构原则必须在组织层面进行，而不是在个人层面。这样可以确保这些原则在早期就得到验证，并且让组织感觉到它们是属于集体的。而且，这样有助促进人们之间的合作，并建立公共价值，培养人们在区分事项重要性方面的共识。
定义优秀的架构原则
要定义好架构原则并不容易。给出一个浅显或凌乱的列表很容易，它们可能缺乏可操作性，以致于无法应用到实际当中。要定义有价值的原则并不容易。
我的长期合作伙伴Nick Rozanski 列出了优秀架构原则所要具备的一些特点[参考3]，如下表。要达到这些标准需要付出一定的努力，不过这样所能得出的原则是很有价值的，它们提供了重要的具有可操作性的行动指南。
(点击放大图像)
什么时候可以违背原则
原则是用来指导设计并达成一致性的。不过有时候架构原则会遭到破坏，因为人们意识不到它们的存在（这种情况很普遍），而有时候人们会忽略它们（如果是这种情况，你一定要找出背后的原因）。
破坏原则需要付出代价，而且通常是长期的代价。所以，如果有人违反了原则，必须给出正当的理由。当发生这种情况时，你必须搞清楚破坏原则所能得到的好处能够抵消它所造成的损失。
遭到破坏的架构原则也会给架构师带来有用的信息。首先，被破坏的原则正好反映了系统设计在某些方面的重要性。其次，如果破坏原则是有正当的理由，那么说明理论和现实之间存在不匹配，我们必须予以纠正。最后，在知道了破坏设计原则所对应的系统点之后，我们就可以在系统演化时有针对性地处理这些点。
虽然人们经常谈论他们系统的架构原则，不过他们经常叫不出它们的名字，也无法解释其中的原理。在系统的生命周期中，特别是在早期阶段，识别、讨论、捕捉和沟通设计原则是非常重要的。这个过程很难，不过最终的结果有助于让理论和实际保持一致。
参考
- D. Greefhorst 和 E. Proper 合著的《Architecture Principles: The Cornerstones of Enterprise Architecture》，由 Springer 出版，2011 年。
- E. Woods 的“Architecting in the Gaps: A Metaphor for Architecture Work”，IEEE Software 杂志，2015 年第 4 期，第 32 卷，第 3335 页。
- N. Rozanski 和 E. Woods 合著《 Software Systems Architecture》，第 2 版，Addison-Wesley 出版，2011 年。
关于作者
Eoin Woods是 Endava 的首席技术官。可以通过 eion.woods@endava.com 联系到他。
查看英文原文： Harnessing the Power of Architectural Design Principles
