方案架构师是负责系统架构以及特定产品的技术标准(包括技术、平台、基础架构)的专家。他们为产品设定前景，他们的分析也是产品的定义、设计、交付和永久支持的成功关键。因此，构架师不仅需要了解业务需求，还需要了解符合企业技术总目标的逻辑性、可扩展性及成本效益。

架构师的重要技能之一就是能从许多不同的角度来看待架构，因为每一个单独的角度可能不完全相关，但结合在一起就可以从总体的角度来看待产品。这些角度包括原则、标准、模式和反模式、经验法则和经验实践，而这些对于决策方向确定和项目评估成功至关重要。

本文将一一介绍这些架构原则。

SOLID五原则

SOLID原则不仅适用于软件开发，也适用于系统的架构。

单一功能原则

每个系统功能(例如服务/模块/应用界面)应该只有一个职责，因此也只有一个变更的理由。尽可能地缩小职责范围，用户便会理解其功能，从而减少错误的发生。

开闭原则

这一原则认为，最好在不修改系统操作的情况下对其进行扩展。尽管提前预测需求的变化可能导致过于复杂的设计，但是能够以现有组件的最小更改来适应新功能是应用程序长期使用的关键。

里氏替换原则

在软件开发中，这一原则意味着派生类必须可替换为它们的基类，但这一原则与勃兰特·梅耶的“契约式设计”关于如何应用于分布式架构有着相似之处：两个服务在进行多次有效沟通后，它们之间形成一种“契约”,其定义了两者的输入/输出、结构和约束。因此：对于具有相同契约的两个分布式组件，一个组件应该可以替换为具有相同契约的其他组件，而不会改变系统的正确性。

接口隔离原则

接口或契约必须尽可能的细化及特定于客户，因此调用客户端并不依赖于它们不使用的功能。这与单一责任原则相辅相成：通过分组接口，我们提倡通过按角色或责任分离的组成，将派生模块与不需要的职责分开解耦。

依赖反转原则

高级模块不应该依赖于低级模块，它们都应该依赖于抽象。同样，抽象不应该依赖于细节，而细节应该依赖于抽象。因此，该原则引入了高层和下层软件组件或层之间的接口抽象以消除双方的依赖关系。

“最小”原则

在下文中，将根据这些原则的名称将他们一起来介绍。

最小惊奇原则

最小惊奇原则(或最少意外原则)指的是，当首次发现某个解决方案或方法时该领域中知识渊博的人不会感到惊讶(受众可能不同，例如最终用户、程序员、测试人员等)。更实际地来说，该原则的目的是利用用户已有的知识，在使用模块时尽量减少他学习曲线，因此任何具有高不可预测性因素的事物都是用来重新设计的好选择。

这一原则适用于架构的每个方面：从命名服务到用户界面的可视化，再到域模型的设计。

有惊喜也有惊吓……

最小省力原则

最小省力原则(也称为齐夫定律)源于一项人类的基本行为：即每个人都倾向于选择走尽可能不费力的道路。例如，如果一项设计遵循于特定的模式，那么下一个开发人员将一次又一次地遵循这一相同的模式，除非有简单得多的方法出现，这时开发人员才会改变这一模式。或者更进一步说，一旦他们找到一项任务的可接受结果，就不需要立即改进当前的解决方案。

最省力等同于最少的工作量。

因此，必须通过建立正确的架构来实现一个好的开端：即设定很高的期望值，并确保每个人都明白工作质量不能在项目周期中受到影响，并且即使未来发生变化，质量也要得到保证。

这个原则的伟大之处在于它的效益是可以推断的：只要把正确的设计放在适当的位置，就可以创建一个架构框架，这将是下一个系统构建的基础。换言之，就能够为组织的软件系统建立一个成功且不过时的模板。

经济学中的原理

以上提到的两个原则有一个共同的主题：即都充分利用了机会成本和推迟决策成本。

机会成本原则

人们每次做选择时，做出的选择都会与一定的价值有关。价值分两部分：效益和成本。选择的机会成本是放弃其后才得到的。为了做出一个好的经济决策，我们希望选择效益最大但成本最低的方案。

例如，摆在面前的有两种选择，一种是内部构建的系统，另一种是现成的供应商产品，如果选择后者，那么机会成本就是开发团队可能会开发出的令人眼前一亮的新系统。

因此，架构所要做的就是权衡不同的选择，做出明智的决定，为项目争取最大的价值。例如，一个非常常见的分歧就是，是创建一个战术上的解决方案，以便快速推向市场，还是创建一个更具战略意义的解决方案，虽说现在成本更高一些，但未来成本会降至最低。

以下是一些可供考虑的因素：

• 架构分析或评估的可用时间是多少?毕竟提出一个解决方案已经非常有挑战性，更不用说好几个了!
• 未来1-3年的产品路线是什么?还有什么其他的项目?能看到任何协同效应吗?
• 目前可能解决的技术债务是什么?
• 反过来想：如果寻求一个战术解决方案将会产生多少新的技术债务?
• 哪些品质要素对企业中的系统最重要?以及它们可能将如何被提议的解决方案所影响?
• 除了架构团队，还有谁是影响决策的利益相关方?公司?你的老板?技术设计部门?每一个利益相关方的核心目标是什么?如何调解有冲突的需求?

最后责任时刻原则

这一原则(也称为延迟成本)源于精益软件开发，强调尽可能长时间地坚持采取重要行动和关键决策。这样做是为了在最后一刻之前不漏掉重要的备选方案，即缩小选择范围，直到得到更全面的信息做出最佳选择。

这个策略不是过早做出决定，而是推迟决定，直到不做决定的成本大于作出决定的的成本之前，保留重要且不可逆转的决策。

而有一种缓解决策过晚风险的方法是建立概念验证(POCs)，来原型化备选方案，并向利益相关者证明他们的需求。

在项目的早期，应该尽可能少地做出有约束力的决定!

结语

架构原则可帮助我们评估整个项目中所做的决策，同时确保其不仅符合项目的总体目标，且符合企业的技术范围。

链接: https://fly63.com/article/detial/5379