解决方案架构师是负责特定产品的系统架构和技术标准（包括技术、平台、基础设施）的专家。他们为产品设定愿景，他们的分析也是产品定义、设计、交付和永久支持成功的关键。因此，架构师不仅需要了解业务需求，还需要了解满足企业整体技术目标的逻辑、可扩展性和成本效益。架构师的一项重要技能是能够从许多不同的角度看待架构，因为每个单独的角度可能并不完全相关，但放在一起可以提供对产品的整体视角。这些观点包括对决策方向和成功的项目评估至关重要的原则、标准、模式和反模式、经验法则和经验实践。本文介绍了这些架构原则中的每一个。SOLID的五个原则SOLID原则不仅适用于软件开发，也适用于系统架构。单一功能原则每个系统功能（例如服务/模块/应用程序接口）应该只有一个责任，因此只有一个改变的理由。尽可能缩小责任范围，用户将了解它的作用，从而减少错误。开闭原则该原则指出，最好在不修改系统操作的情况下扩展系统。尽管提前预测需求的变化会导致设计过于复杂，但能够在对现有组件进行最少更改的情况下适应新功能是应用程序长期使用的关键。Liskov替换原则在软件开发中，这个原则意味着派生类必须可以被它们的基类替换，但是这个原则与BrandtMeyer的“DesignbyContract”有关，关于它如何应用于分布式架构相似性：在两个服务有效通信之后次，它们之间形成了一个“契约”，它定义了两者的输入/输出、结构和约束。因此：对于具有相同合约的两个分布式组件，一个组件应该可以被另一个具有相同合约的组件替换，而不会改变系统的正确性。接口隔离原则接口或契约必须尽可能细化和特定于客户端，因此调用客户端不依赖于它们不使用的功能。这与单一职责原则密切相关：通过对接口进行分组，我们提倡通过按角色或职责分隔的组合将派生模块与不需要的职责分离。依赖倒置原则高层模块不应该依赖低层模块，它们都应该依赖抽象。同样，抽象不应该依赖于细节，而细节应该依赖于抽象。因此，该原则引入了高层和低层软件组件或层之间的接口抽象，以消除双方的依赖关系。下面将根据这些原则的名称来介绍“最低限度”原则。ThePrincipleofLeastSurprise最少惊奇原则（或最少惊奇原则）是当解决方案或方法首次被发现时，该领域的知识渊博的人不会感到惊讶（受众可能会有所不同，例如最终用户、程序员、测试人员、ETC。）。更实际地说，该原则旨在利用用户的现有知识并在使用模块时最大限度地减少他的学习曲线，因此任何具有高不可预测性的因素都是重新设计的好选择。这个原则适用于架构的每个方面：从命名服务到用户界面的可视化，再到领域模型的设计。有惊喜也有惊吓……最省力原则最省力原则（也称为Zif定律）源于一种基本的人类行为：即每个人都倾向于选择花费尽可能少的努力的路径。例如，如果设计遵循某种模式，下一个开发人员将一遍又一遍地遵循相同的模式，除非出现更简单的方法，此时开发人员将更改模式。或者更进一步，一旦他们找到了可接受的任务结果，就没有必要立即改进当前的解决方案。最少的努力等于最少的工作量。因此，良好的开端必须通过正确的结构来实现：即设定高期望并确保每个人都明白，在项目周期中不能损害工作质量，即使未来发生变化，质量也能得到保证。这个原则的伟大之处在于它的好处是可以推断的：只需将正确的设计放在适当的位置，您就可以创建一个架构框架，它将成为构建下一个系统的基础。换句话说，可以为组织的软件系统建立一个成功的、面向未来的模板。经济学中最简单的道路原则上面提到的两个原则有一个共同的主题：它们都充分利用了机会成本和延迟决策成本。机会成本原理人每次做出选择时，所做的选择都会与一定的价值相关联。价值有两个组成部分：收益和成本。选择的机会成本是在放弃后获得的。为了做出好的经济决策，我们要选择收益最大、成本最低的方案。例如，如果要在内部构建的系统和现成的供应商产品之间做出选择，选择后者的机会成本就是开发团队可能开发的产品。新系统。因此，架构所要做的就是权衡不同的选择并做出明智的决定，以获得项目的最大价值。例如，一个非常普遍的分歧是，是创建一个战术解决方案以快速进入市场，还是创建一个更具战略意义的解决方案，现在成本更高但将来会最大限度地降低成本。以下是一些需要考虑的因素：可用于架构分析或评估的时间是多少？毕竟想出一个方案就已经很困难了，更何况是几个！未来1-3年的产品路线图是什么？还有什么其他项目？你能看到任何协同效应吗？当前可以解决的技术债务是什么？反过来想：如果采用战术解决方案，将会产生多少新的技术债务？重要的？他们可能如何受到提议的解决方案的影响？除了架构团队，还有哪些利益相关者会影响决策？公司？你的老板？技术设计部？每个利益相关者的核心目标是什么？如何调解相互冲突的需求？最后责任时刻原则这一原则（也称为延迟成本）起源于精益软件开发，强调尽可能长时间地坚持重要行动和关键决策。这样做是为了直到最后一刻才不会错过重要的备选方案，即缩小选项范围，直到有更全面的信息可供选择，以做出最佳选择。与其过早地做出决定，不如推迟决定，直到不做决定的成本大于做出决定的成本，保留重要且不可逆的决定。降低决策太晚风险的一种方法是构建概念证明(POC)来制作备选方案的原型，并向利益相关者展示他们的需求。在项目的早期，应该做出尽可能少的有约束力的决定！Epilogue架构原则帮助我们评估整个项目中所做的决策，同时确保它们不仅符合项目的总体目标，而且符合企业的技术范围。下图突出显示了本文阐述的五项原则：
