大家好，我是灸哥，公众号之所以取名为“漫谈”，就是不想规矩自己，不想设定主题，当然如此做，已经不是一个专业的自媒体号了，不过灸哥喜欢这种无拘无束，想谈什么就谈什么的感觉～

今天这篇文章，主要是把作为一名架构师必知必会的理论知识做一个汇总，具体的内容前面和大家聊过，在本文末都有对应的内容跳转链接。之所以做这个汇总，一个是在做架构师培训的课程，另外一个是自己也需要梳理一下理论体系了，故而分享给大家。

本文主要包括：

1. 架构是什么：定义、目标、职责、类型

2. 软件架构发展史

3. 常见软件架构设计模式

4. 架构师要掌握的技术理论

5. 架构基础设施能力

6. 架构组织文化

7. 架构设计遵循定律

软件架构是什么？

架构是软件系统的顶层结构，是对软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

软件架构设计的目标有哪些？

通俗地讲，架构设计的目标就是追求使用最小的人力成本、最高的质量、更高的客户满意度来满足构建和维护系统的需求。

再精炼点说，架构设计的目标，可以概括为四个字：多、快、好、省，这四个字涵盖了：效率、成本、稳定、运维、演进、容错、安全。

从所架构的系统层面讲，就是要追求一个软件系统的：可靠性、安全性、可扩展性、可定制化、可伸缩、可维护性、客户体验、市场时机。

架构的职责是什么？

1. 将不变的部分从变化中抽象出来，沉淀为稳定的组件

2. 管理多个组件之间的依赖，识别、定位、管理组件的边界和上下文，让变化容易暴露和识别

3. 管理多维度的变化

4. 探求将业务逻辑变成可配置的易变更的实现方式

架构的类型有哪些？

1. 业务架构：对业务的定义和划分，顶层设计，影响着组织结构和技术架构

2. 应用架构：根据实际业务场景设计应用的结构、制定规范、定义接口和数据交互协议等，尽量把复杂度控制在一个可接受的范围内

3. 系统架构：根据业务场景综合考虑系统的非功能属性（性能、安全性、可用性、稳定性等）做出技术选型

4. 数据架构：聚焦数据的收集、处理以及提供统一的服务和标准，目的是统一数据定义规范、标准化数据表达，形成有效易维护的数据资产，形成数据使用闭环

5. 物理架构：关注软件元件在硬件上的部署，包括机房搭建、网络拓扑等

6. 运维架构：负责运维系统的规划、选型、部署上线，建立规范化的运维体系。运用技术手段控制成本和优化成本。通过工具化及流程提升运维效率。推动及开发高效的自动化运维

软件架构发展史

在软件架构演进历程中，每一种风格的架构诞生都并非一蹴而就，而是经历了持续的演变和优化。

原始分布式时代

Unix 的分布式设计哲学：“Simplicity of both the interface and the implementation are more important than any other attributes of the system — including correctness, consistency, and completeness.” （保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。） —— Richard P. Gabriel，The Rise of 'Worse is Better，1991

原始分布式时代标志着对分布式架构最初步的探索与研究。由于硬件限制，将系统拆分到不同的机器上引发了一系列的问题，包括服务发现、跟踪、通信、容错、隔离、配置、传输、数据一致性和编码复杂度等多方面的挑战。然而，正是这个阶段，许多技术和概念被提出，对 Unix 系统和今天的计算机科学的多个领域产生了深远的影响。

时代价值 RPC、DFS 概念的开创

时代教训 某个功能能够进行分布式，并不意味着它就应该进行分布式，强制追求透明的分布式操作，只会自寻苦果

单体系统时代

出现最早、应用最广泛、使用最为普遍、统治历史最长的架构风格。对于小型系统，仅需单台机器支撑运行的情况下，单体是完全合理的选择。

单体架构出现缺陷的两个前提：

1. 系统的性能需求超过了单机

2. 研发团队超过了“2 Pizza Teams”范畴

SOA 时代

标志着分布式服务被广泛应用，有完善的理论和工具，解决了分布式系统中需要关键技术问题。

有标准的技术组织、明确的设计原则、确定的协议和通信机制等，“妄想”总结出一套自上而下的软件研发方法论，解决研发过程中的所有各种问题。

过于严格和复杂的规范定义，复杂性太高，不具有普适性。但很多概念对后续架构演进起到了很好的促进作用：服务间的松散耦合、服务注册、服务发现、服务治理、服务隔离和编排等。

微服务时代

起初是对 SOA 的轻量级补救方案，真正崛起是 2014 年“《 Microservices：a definition of this new architectural ter 》”的文章的发表。

微服务降低了复杂性，但带来了新挑战：没有统一的规范和约束，对架构师和研发人员要求更高

云原生时代

云原生时代的最大变化是跨越了软件与硬件之间的界限。对架构演进的最大贡献是容器化技术的出现。

在云原生时代并非只是解决之前的问题，而是提出了一种新的思维方式，软件和硬件的界限变得模糊，软件系统的灵活性不再受限于硬件制约。而且与业务无关的技术问题也可以从软件剥离，在硬件的基础设施内解决，让软件可以更专注于业务。

云原生时代新的挑战是不能完美解决一些处于应用系统与基础设施边缘的问题，可以使用服务网格的边车代理模式解决。

无服务时代

分布式为解决单台机器性能瓶颈问题，而无服务为了解决分布式中面临的容错能力、技术异构、职责划分等问题。

无服务架构中只涉及到后端设施和函数两部分：

1. 后端设施：指数据库、消息队列、日志、存储等用于支撑业务逻辑运行，但本身无业务含义的技术组件，都在云上，被称为后端即服务（BaaS）

2. 函数：指业务逻辑代码，运行在云端，无需考虑算力和容量问题（仅技术不考虑，财务还是需要考虑钱的），被称为函数即服务（FaaS）

无服务的优势：

1. 开发者专注业务，不需要考虑技术组件

2. 不需要考虑如何部署和运维，完全托管给云

3. 只要有钱，算力无限大

当前阶段无法普适：冷启动、无状态、运行时间限制等。暂时适用场景受限。

架构演进是一个不断推陈出新的过程。无论是单体、微服务还是无服务，都是为了更好地满足业务需求而服务的工具，选择合适的架构模式需要综合考虑业务特点、团队实力以及技术栈的适配性。通过对架构演进历史的了解，我们可以更好地应对未来的挑战，构建出更加稳健和创新的系统。

常见软件架构设计模式

经典 MVC 三层架构

经典的 MVC 架构（Model-View-Controller）架构是软件系统架构设计中的经典，它将应用程序分为三个主要部分：

1. 模型（Model）

2. 视图（View）

3. 控制器（Controller）

这样的三层架构有助于实现业务逻辑的分离，提高代码的可维护性和可扩展性。

CQRS 架构

命令查询职责分离模式（Command Query Responsibility Segregation，CQRS）是一种软件架构模式，它通过从业务上分离修改（Command：增、删、改，会对系统状态进行修改）和查询（Query：查，不会对系统状态进行修改）的行为，使逻辑清晰，提高系统的可维护性和灵活性。

优点

1. 业务逻辑清晰：读写操作分离，业务逻辑清晰，降低系统复杂性

2. 可维护性增强：读写模型分离，可独立演化和优化，可维护性增强

3. 可扩展性增强：支持独立扩展读或写部分，灵活性使系统更容易适应不断变化的需求

4. 性能优化便捷：可专门优化读模型，更好地满足查询性能要求

不足

1. 结构复杂度高：引入了两个独立的读模型和写模型，系统结构复杂度高，维护和理解两个模型之间的关系成本高

2. 冗余代码多：由于独立的读写模型存在导致代码冗余，特别是一些共享的业务逻辑

3. 性能问题出现：涉及多次数据库操作，会导致性能问题，特别是频繁读写的操作场景

4. 工作流不直观：因为读写模型的独立，功能任务会分解为多个步骤，导致工作流比较难理解

5. 缺乏标准化：没有广泛的标准，团队在实践中要适时调整，不然容易缺乏一致性和规范性

结论

在对系统的可维护性、可扩展性和性能有较高要求的情况下，CQRS 可能是一个不错的选择。

六边形架构

六边形架构（Hexagonal Architecture）也称为端口适配器模式，是 Alistair Cockburn 在 2005 年首次提出的一种软件架构模式。其主要目标是将应用程序的核心逻辑与特定的输入/输出技术解耦，使其能够更灵活的应对变化和演化。

三个原则

1. 明确分层层次 Explicitly separate Application，Domain，and Infrastructure：在六边形架构中，明确分离应用程序（Application）、领域（Domain）和基础设施（Infrastructure）是关键的设计原则，这种分离使开发者将关注点分离开，每一层都可以独立变化而不影响其他层，提高了系统的可维护性、可测试性和可扩展性。

2. 依赖关系指向领域层 Dependencies are going from Application and infrastructure to the Domain：确保领域层保持独立性，不依赖于具体的应用程序逻辑或基础设施技术，提高系统的可测试性、可维护性和可扩展性。技术上，就是 Application 和 Infrastructure 都不能直接互相调用对方的功能或者操作，只有经过 Domain 的接口才能沟通，确保 Domain 部分具有完整的独立性，不受 Application 和 Infrastructure 变更的影响，从而保持稳定，这样的代码结构易读、易管理、易维护。

3. 使用端口和适配器隔离边界 We isolate the boundaries by using Ports and Adapters：六边形架构使用端口和适配器模式来隔离系统的边界，以提高系统的可测试性、可维护性和灵活性，目标是将业务逻辑与外部环境解耦，让系统的各个部分更容易替换、测试和理解。

特点

1. 对称性：系统的设计围绕着一个中心的应用核心组件，所有的交互都必须通过这个中心

2. 隔离性：应用程序的核心组件被一层薄的适配器包围，使得它对外部环境的变化免疫

3. 可插拔性：系统可以通过改变其适配器来更改接口，并适应不同的上下文

优点

1. 灵活性：当外部环境发生变化时，只需要修改适配器即可，而无需触及应用程序的核心

2. 测试友好：可以轻松模拟和替换适配器，从而更容易测试应用程序的核心部分

3. 低耦合：应用程序的核心部分与外部环境完全解耦，使其更易于维护和扩展

不足

1. 设计复杂度高

2. 需要花费更多时间进行需求分析和设计

3. 学习曲线陡峭，需要具备软件设计知识

总结

六边形架构是一种有助于提高代码代码质量和维护性的设计方式，但它也有比较高的学习成本和实施难度。在实际应用中，可以根据具体项目的规模和复杂程度以及团队的技术能力，灵活运用此模式。

洋葱架构

洋葱架构（Onion Architecture）是由 2008 年，Jeffrey Palermo 提出，它在端口和适配器架构的基础上将领域放在应用中心，将用户用例和基础设施放在外围，这种设计思路类似于六边形架构，都是通过适配器代码将应用核心从对基础设施的关注中解放出来，以避免基础设施代码渗透到应用核心之中，使得框架和中间件需要改变替换的时候更加轻松，不会影响到核心领域。

设计原则

1. 依赖性：洋葱架构中的圆圈代表不同的责任层，进入越深越接近领域和业务规则，外圈代表机制，内圈代表核心领域逻辑，外层依赖于内层，而内层对外圈一无所知

2. 数据封装：每个圈层封装内部实现细节，向外层公开接口，在内层定义抽象接口，在外层提供具体实现，确保专注于领域模型，而不必过多地担心实现细节。运行时，可以使用依赖注入框架，将接口和实现连接起来

3. 关注点分离：应用系统被分为多个层级，每一个层级都有一组职责，并解决不同的关注点

4. 耦合性：低耦合性，一个模块和另一个模块交互时不需要关注另一个模块的内部具体实现，所有的内部层级不需要关注外部层级的具体实现

架构分层

1. 应用服务层：负责协调请求步骤的服务，不应该有任何业务逻辑，应用服务与其他服务交互来满足客户请求

2. 领域服务层：负责保持领域逻辑和业务规则，所有的业务逻辑应该作为领域服务的一部分来实现。领域服务由应用服务协调，服务于业务用例。不是简单的 CRUD 服务

3. 领域模型层：封装属性和实体行为

4. 基础设施层：在洋葱架构中的最外层，负责与外部世界交互，不解决任何领域的问题，没有任何逻辑

5. 可观察性服务层：负责监控应用，可以用于数据收集（指标、日志、痕迹）、数据存储、可视化等

优势

洋葱架构建立在一个领域模型上，各层之间通过接口交互，其设计思想是在领域实体和业务规则构成架构的核心部分时，尽可能将外部依赖性保持在外：

1. 提供灵活、可持续和可移植的架构

2. 各层之间没有紧密耦合，且有关注点的分离

3. 所有代码都依赖更深的层或者中心，提高可维护性

4. 提高整体代码的可测试性，单元测试可以在单独的层创建，不会影响其他的模块

5. 框架/技术可以容易改变而不影响核心领域

不足

1. 设计复杂性：多个端口和适配器需要额外的设计工作且增加了系统复杂度

2. 维护困难：洋葱架构的系统非常复杂对应的维护难度也比较高

总结

洋葱架构适用于大型、复杂的应用程序，对于需要长期维护和演进的系统，其设计理念有助于降低变更的风险，提高系统的可靠性和可扩展性，在具体应用时，可以根据项目规模和团队技术水平做出适当的调整。

DDD

领域驱动设计（Domain-Driven Design，DDD）是一种开发思想，强调将软件系统的注意力集中在业务领域上，将领域视为应用的核心。在架构设计中，DDD 提供了一种不同的思维方式，从以数据为中心的传统模型转向以业务领域为中心的模型。

核心概念

1. 领域层：对应于洋葱架构中的内层，是 DDD 中的核心，在这一层，通过领域模型的建立，深入理解业务概念和规则，通过建模，将专业领域的知识融入软件设计，实现软件系统与业务场景的紧密结合

2. 领域模型：用于捕捉业务概念和规则的模型，通过建立领域模型，将业务领域的复杂性呈现在软件系统中，提高系统对业务的表达能力

3. 实体/值对象/聚合：DDD 中的基本概念，用于构建领域模型，实体表示具有唯一标识的对象、值对象是没有唯一标识的对象、聚合是一组相关对象的集合

优势

1. 深入理解业务：通过领域建模，开发团队能更深入理解业务需求和规则，使软件系统更加贴近实际业务场景，提高系统的可理解性

2. 可维护性高：DDD 通过清晰的领域模型，降低了系统的复杂度，模块化的设计使得系统更易于维护

3. 适应性好：领域模型的建立使得系统更加灵活，能够适应业务领域的变化

总结

DDD 在当前业内基本上分为两个派系：

1. 理论派：重规范，重系统训练，以方法体系为重

2. 实践派：重实践，重个人感悟，以思想体系为重

从对 DDD 这几年的关注和学习，我把它分成四个部分：

1. 关于结构理论：DDD 是用来进行战术建模与战略建模的

2. 关于过程理论：DDD 是用来指导系统重构与软件工程的

3. 关于语言理论：DDD 是建立关于业务模型的统一语言的

4. 关于建模理论：DDD 是用来指导模型驱动的领域建模的

领域驱动设计在架构设计中的核心思想是将业务领域置于关注的焦点，通过领域模型的建立和应用，实现软件系统与实际业务的密切结合。这种思想的应用使得架构更加灵活，更易于理解和维护。

COLA 架构

COLA 架构，即整洁面向对象分层架构，Clean Object-oriented and Layered Architecture，COLA，是一种旨在在架构层面控制软件复杂度的面向对象分层架构。该架构思想不仅提供了理论指导，还包含了具体实施的框架和工具，以确保整个软件系统保持清晰、可维护和可扩展。

四层架构

1. 展现层：负责处理用户界面和用户输入，呈现数据给用户。包括页面、控制器等组件

2. 应用层：包含应用的核心业务逻辑，协调领域服务的调用。不包含具体业务规则，主要用于编排业务流程

3. 领域层：包含领域模型、实体、值对象、聚合等，体现了系统的业务核心。包含具体的业务规则和业务逻辑

4. 基础设施层：处理与外部系统的通信、数据库访问等技术实现。保持与具体技术的解耦，确保系统的灵活性

设计规范

1. 组件规范：规定系统中组件的职责和行为，确保组件的设计符合整体架构

2. 包规范：定义不同包的职责范围，确保包的划分清晰，避免功能交叉

3. 命名规范：统一命名规范，提高代码的可读性，降低团队协作的沟通成本

TOGAF

TOGAF（The Open Group Architecture Framework）是一种通用的企业架构开发框架，由 The Open Group 推出，它提供了一种综合性的方法，帮助企业定义和改进其 IT 战略、规划和实施过程。

DODAF

DODAF（Department of Defense Architecture Framework）是由美国国防部于2003年推出的系统架构框架，旨在建立一套系统架构开发、管理、改进和实施的标准。

在软件架构的领域中，我们介绍了多种经典架构模式，每一种都为解决特定问题和满足不同需求提供了独特的视角和解决方案，旨在帮助大家理解不同架构设计风格的适用场景，为未来的项目开发提供丰富的选择。记住，架构设计没有银弹，选择最适合您的项目和团队的架构才是最为关键的！

架构师要掌握的技术理论

编程三范式

编程范式是程序设计的基本思想和方法，对于程序员来说，他是告诉我们在实际编码和设计的过程中不能做什么，而非可以做什么。了解和灵活运用编程范式，有助于构建更加清晰、灵活、可维护的代码。

1. 结构化编程：是基于过程的一种编程范式，将问题分解为一系列的步骤，每个步骤都由一个过程或函数表示。强调程序的执行过程，是用于简单的任务和流程

2. 面向对象编程：是一种以对象为基础的编程范式，将数据和操作封装在对象中，强调对象之间的交互和关系。核心思想是通过抽象、继承、封装和多态等概念，提高代码的重用性和可维护性

3. 函数式编程：是一种以函数为基础的编程范式，将计算视为数据函数的求值过程。强调纯函数、不可变性和无副作用，通过组合函数来构建复杂的系统

编程范式和架构设计的关系：

1. 结构化编程是在做各个模块设计和实现时的基础要求

2. 面向对象编程中比如多态是跨越架构边界的手段

3. 函数式编程是用来规范和限制数据存放位置与访问权限的手段

三范式与架构设计中的功能性、组件独立性、数据管理是密切相关的。

架构设计原则

1. 合适原则：架构设计应该全面考虑时间、人力、能力、效率、成本，选择当前最为合适的方案

2. 简单原则：在满足功能需求的前提下，追求简洁和可读性

3. 演化原则：指导设计出能够适应未来变化的重要原则，要求技术人员具备前瞻性

软件设计七原则

做好一个系统，要先从写出整洁和易维护的代码开始。如果代码质量不佳，那架构能起到的作用就不会太大，多好的架构也绷不住堆砌的烂代码。反之，如果架构设计的不太理想，代码写的再好其实也无太大用处。两者之间是相辅相成，互相成就的。

1. SRP 单一职责原则

2. OCP 开闭原则

3. LSP 里氏替换原则

4. ISP 接口隔离原则

5. DIP 依赖倒置原则

6. CARP 合成/聚合复用原则

7. LoD 迪米特原则

组件构建原则

组件构建原则是用来指导如何将各个组件组合成独立完成部署的软件系统，组件聚合是常用的组件构建方法。在软件架构设计中，组件聚合是指将多个相关的组件组合在一起，形成一个相对独立的、可交付的子系统或模块。

1. REP 复用/发布等同原则：REP 是一个关注重用性的原则，他要求在设计组件时，尽可能地提高组件重用性，减少重复劳动。核心思想是将通用功能和行为封装为可重用的组件，以便在多个应用场景下使用

2. CCP 共同闭包原则：CCP 是一个关注耦合性的原则，他要求在设计组件时，尽可能地降低组件之间的耦合度，提高组件的独立性

3. CRP 共同复用原则：CRP 是一个关注内聚性的原则，他要求在设计组件时，尽可能地提高组件的内聚性，减少组件内部的复杂度

组件耦合原则

组件构建原则指导我们如何设计组件，而耦合原则是用来指导我们如何设计组件之间的关系。耦合是指组件之间相互依赖的程度，耦合度的高低直接影响可维护性、可扩展性和可重用性。

1. 最小化耦合原则

2. 接口耦合原则

3. 依赖倒置原则

4. 单一职责原则

组件耦合原则对于软件架构的健壮性和可维护性至关重要。通过遵循控制组件耦合原则，软件设计者可以建立灵活且可扩展的系统，提高系统的稳定性和可维护性。在设计和开发过程中，不断优化耦合关系，确保系统在不同阶段都能够维持良好的设计质量。

识别复杂度

在进行软件架构设计时，识别复杂度是非常重要的一环。以下是一些方面，可以帮助你在架构设计中识别和评估复杂度：

1. 需求分析：深度了解业务需求、功能需求和非功能需求是进行架构设计的输入，也是评估复杂度的关键因素

2. 关键元素：数据库、服务器、网络带宽、安全合规等

3. 评估交互：不同元素之间的交互，比如数据传输、调用方法、发送消息等

4. 性能和扩展性：高性能和可扩展性是基本要求。性能主要考虑 RT 、 QPS 等，扩展性是关注是否能适应业务增长和新技术引入

5. 安全性：包括系统身份验证、用户授权、数据隐私合规等，还需要考虑潜在的攻击面、敏感数据的暴露程度和合规要求

6. 技术债：对现有系统进行架构重构和升级时，是一定要了解现有系统的技术债务，比如代码结构、代码规范、代码质量、技术栈的兼容性等

7. 人员技能和经验：团队成员的技术能力、技术经验和熟悉的技能、工具、语言等

8. 风险评估和管控：识别可能的风险因素以及制定和实施有效的风险管控策略

9. 迭代和反馈：采用迭代式的研发模式，从每个迭代中学习并及时调整，通过收集反馈和监控指标，更好地理解复杂度并进行优化

10. 文档和沟通：清晰的文档记录，包括需求文档、技术文档和代码注释，有效的沟通

识别风险项

在软件架构设计过程中，对可能出现的风险因素进行识别、评估和解决是至关重要的，以下是一些常见的架构设计风险和相应的识别与解决方法：

1. 需求变更风险：过度的需求变更可能导致架构设计的频繁调整，增加开发成本，因此，在架构设计阶段，要充分了解业务需求，进行详尽的需求分析和业务建模，以减少对需求变更的敏感性

2. 技术债务风险：由于技术决策的短期利益而产生的长期问题。比如选择不合适的编程语言、框架等都会增加架构设计的复杂度和维护成本。因此，在架构设计阶段，对现有系统的技术债务进行评估和管理，确保技术决策考虑了长期影响

3. 性能风险：性能是考虑一个软件产品系统的重要指标，如果性能不行，你的架构再厉害都是无稽之谈。性能风险包括响应时间慢、吞吐量低、高并发处理能力不足、大数据处理能力差等。因此，在架构设计阶段，需要对产品系统的性能进行充分评估和优化，确保设计出来的架构满足性能需求

4. 扩展性风险：业务和技术都是不断往前发展的，要求系统架构是能够适应业务的增长和新技术的引入。如果架构不具备扩展性，就会导致系统架构无法适应未来的业务增长和新技术的引入。因此，在在架构设计时，设定目标，确保架构在一定时期内不需要变动，并具备在三年内通过配置化、灵活扩展的方式支撑业务变化的能力

5. 安全性风险：安全性一般包括身份验证、授权、数据隐私合规、资金安全等，这些一旦出现风险会导致数据泄露、系统被攻击、资金亏损等。因此，在架构设计阶段，要对业务场景进行全面的分析，对安全层面的风险进行充分评估和应对方案的设计，确保系统可以具备强安全性

6. 可维护性和可读性风险：缺乏维护性和可读性会导致系统难以维护和更新。因此，在架构设计时，要注重代码的清晰结构、规范和文档记录，确保系统具备良好的维护性和可读性

7. 集成风险：与其他系统或组件集成时可能出现的问题，如接口不兼容、数据格式协议不一致等。因此，在架构设计阶段，充分考虑集成问题，定义清晰的接口和协议，进行充分的集成测试

8. 项目管理风险：成员技能不足、沟通不畅、进度管控不当等问题可能导致项目失败。因此，在项目管理中，注重团队成员的培训与技能提升、有效的沟通机制、合理的进度管控和风险管理

软件架构设计是一个综合性的过程，需要考虑多个因素。需要遵循设计原则、构建原则、耦合原则，识别复杂度和风险以及有效地解决风险，是构建可靠、灵活和可维护性软件系统的关键。同时，通过团队的不断学习、迭代和有效的沟通，可以更好地适应业务和技术的变化，确保软件系统的长期健康。

架构组织文化

说到软件架构时，不仅仅是指技术上的设计和决策，更涉及到组织的文化和价值观。构建一个强大而可持续的软件架构需要超越单纯的技术选择，它需要一个健康的架构文化的支持。

架构文化是一个组织内部的共同信仰，是开发团队在设计和构建软件时所遵循的原则和价值观。它涉及到如何做决策、如何处理技术债务、如何平衡创新和稳定性，以及如何与业务目标相一致。在一个强大的架构文化中，每个团队成员都能够理解架构的重要性，并为其贡献力量。

架构思维培养

架构思维是一种综合性的思考方式，旨在理解系统的整体架构，权衡不同设计选择，并考虑长期演进。在培养架构思维的时候，需要关注以下方面：

1. 系统思维：帮助团队成员从整体角度看待系统，理解各个部分之间的相互关系，以及它们对系统整体性能和可维护性的影响

2. 风险管理：培养团队在设计和决策时能够识别和评估潜在的技术风险，以及采取措施来降低这些风险的能力

3. 演进性思考：强调系统的演进性，使团队能够做出既能满足当前需求又具备良好演进性的设计和决策

架构技能培训

领域建模小组

1. 业务理解能力：强调团队对业务领域的深刻理解，使得架构决策更加符合业务需求

2. 业务抽象能力：培养将业务问题抽象为可操作概念的能力，以更好地进行系统设计

3. 业务建模能力：提高建模技能，包括流程图、时序图等，以清晰表达业务过程

架构小组

1. 解决问题：强调团队成员在面对复杂问题时的解决能力，培养快速而准确的决策能力

2. 架构演化：学习如何适应变化，进行系统演化，以满足业务需求的变化

3. 架构前瞻：提升团队对未来技术趋势的洞察力，确保系统架构具备良好的前瞻性

规约/最佳实践

1. 数据库设计以及 SQL 使用规约

2. 缓存使用规约

3. 中间件使用规约

4. 接口规范

5. JAVA/JS/Python 等代码规范

6. 常见业务架构/常见场景架构实践

7. 隔离关注点防腐

架构设计遵循定律

康威定律

软件架构设计第一定律源自《人月神话》，强调组织的沟通方式会在系统设计中得以表达。具体说，沟通方式的选择将在系统的边界、护城河以及整体结构上留下痕迹。因此，团队间的沟通方式直接影响到架构的形成。

墨菲定律

Anything that can go wrong will go wrong！

墨菲定律强调了在任何情况下，一切可能出错的事情最终都会出错。这为系统设计者提供了一种思维方式，即预测和准备可能的问题，以便更好地处理和修复。

Amdahl 阿姆达尔定律

Amdahl 阿姆达尔定律描述了在并行计算中，系统的加速受制于可并行化部分的比例。即使系统中只有很小一部分是串行的，其影响也会在整体性能上产生明显的限制。

Gustafson 古斯塔夫森定律

Gustafson 定律为系统设计者提供了一种思考方式，即通过增加计算资源来提高系统的计算量。这对于需要处理大规模计算的领域（如机器学习、大数据）具有指导意义。

算法设计领域定理：丑小鸭定理

丑小鸭定理表明一个看似不够优秀的算法在适当的情境下，可能会比看似更好的算法表现更好。这提醒我们在选择算法时，要结合具体场景和需求，不仅仅追求理论上的最优解。

算法设计领域定理：没有免费的午餐定理

这个定理强调了在算法设计中，没有一种算法能够在所有问题上表现最优。选择最适当的算法需要考虑到问题的特征和约束条件，避免生搬硬套。

关联阅读

1. 架构设计遵循定律以及企业如何构建架构文化
2. 作为一名程序员如何转型成为架构师
3. 聊聊前端架构设计与后端架构设计的区别