架构(architecture)一词最早来源于建筑学，是指在建筑上如何依靠内部的支撑物互相结合从而稳固构造的方式。

很多人一听到“软件架构”，脑海里浮现的是微服务、云原生、中间件、高并发……一堆听起来很厉害的技术名词，于是下意识觉得：架构是技术专家的事，普通人看不懂，也不需要懂。

但如果架构只是技术问题，为什么所有架构设计的讨论，开口谈的都是“业务目标”？

因为软件架构从来不是技术名词的堆砌，而是一条从业务价值出发、层层传导、最终落地的完整链路。

架构展示的是一张静态图纸，而背后反映的是一条从业务出发、最终落地的完整链路：

原始需求收集→ 需求分析 → 方案设计 → 开发&测试 → 实施部署 → 运维运营

软件架构设计，可以浓缩成一句话：

一、架构的定义与本质

（一）架构的经典定义

Martin Fowler：架构包含两点——其一，架构是最高层次的系统分解；其二，架构是系统中不易改变的决定。

Ralph Johnson：架构是一种主观的东西，是专家级开发人员对系统设计的一些可共享的理解，表示为系统中可被理解的部分以及它们之间的关系。

（二）架构的教科书式定义

引自维基百科，教科书式的定义:

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

软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标作为绘图员画图的基础一样，软件架构师或系统架构师陈述软件架构以作为满足不同客户需求的实际系统设计方案的基础。

（三）架构的层次分解

域视角：区分问题域（业务本身）和解决方案域（软件实现系统）；

问题域通过业务能力、限界上下文做业务分解，一般分为：核心域/支撑域/通用域。

解决方案域可以纵向分层（核心业务，垂直切分，典型IPDS、MVC和DDD四层：Presentation/Application/Domain/Infrastructure）和横切关注点（通用能力，贯穿多层，如：鉴权、日志、告警、工作流、加密脱敏、AI问答等）。

（四）架构设计的基本原则

一是优先按照问题域分解；二是面向质量属性（非功能性需求）定义架构策略，质量属性包括外部质量属性（性能、安全、可靠、易用等）和内部质量属性（可维护、可扩展、代码高内聚低耦合、可测试等）；三是选择合适的架构风格和模式，如三层、四层、六边形、整洁架构。

（五）技术维度与商业维度

架构设计不只是技术维度的广泛认知，更是商业维度的全局把控。技术目标，是按照流程完成代码和功能的交付；业务目标，是代码上线后能为公司创造商业价值。两者缺一不可。

二、贯穿项目全流程的六大阶段：架构在哪里产出

软件架构是基于画出的静态图纸，沿着项目全流程逐步产出的一组成果。理解软件架构，最好的方式是把它放进项目全流程里，看每个阶段该产出什么架构、给谁用、解决什么问题。

项目全流程：客户原始需求收集→ 需求分析 → 方案设计 → 开发&测试 → 实施部署 → 运维运营。每个阶段产出的架构成果、目标用户与核心作用，汇总如下表。

补充说明

• 第三方集成架构：当存在多个外部系统对接时，在需求分析/方案设计阶段单独输出，重点描述内外系统接口、协议与交互链路，属于系统架构子集。

• 项目架构：项目范围、任务拆解、资源规划、进度计划属于项目管理工作（WBS、项目计划），通过项目来支撑各个架构的产出落地。

三、架构的三大分层关系与完整链路

将项目六大阶段输出的架构进行分类，归纳为三个层级，共同形成了相互依赖关系的完整链路；同时包含三类关键附属架构：第三方集成架构、部署架构（系统组网拓扑）、运维架构。

源头层（需求逐层传导）：业务架构（做什么）→ 产品架构（需要什么产品）→ 应用架构（系统怎么建）

附属架构：第三方集成架构，属于系统架构子集，在需求分析阶段产出，当需要对接外部系统时，补充定义外系统接口集成的方式，辅助完成业务到产品到应用的跨系统需求传导。

支撑层（给系统装上引擎和底座）：数据架构（为应用提供数据能力）、技术架构（为应用/ 数据提供技术底座）

附属架构：运维架构，属于支撑层重要组成部分，依托技术架构输出监控、告警、日志、备份、容量规划等运维体系策略，为整套系统提供稳定运行的运维能力底座。

落地层（把图纸变成交付）：项目架构（把设计拆成任务，保障落地交付）

附属架构：部署架构（系统组网拓扑），承接技术架构、运维架构的输出成果，作为落地层的物理实现，描述应用组件部署位置、资源分配、网络链路，把逻辑架构映射为物理环境，直接指导系统上线实施。

源头层需求逐层传导：业务架构是所有架构的核心，产品架构衔接业务与应用；当涉及外部系统对接，由第三方集成架构定义跨系统协作规则；应用架构必须满足产品功能需求；支撑层为应用提供数据能力与技术底座，运维架构同步规划整套系统运维保障策略；落地层通过部署架构完成逻辑架构向物理环境的转换，再由项目架构把全部架构设计拆成任务、保障整体交付。

六种架构连同附属架构，咬合成一条完整的链：

（1）业务架构是所有架构的核心：产品、应用、数据、技术架构都必须对齐业务目标，否则就会偏离业务价值；

（2）产品架构衔接业务与应用：应用架构必须满足产品功能需求；若涉及外部系统对接，第三方集成架构定义内外系统交互边界，避免外部系统耦合侵蚀内部业务逻辑；

（3）应用架构依赖数据和技术架构：没有数据模型无法处理库存，没有高并发方案无法支撑秒杀流量；运维架构基于技术架构，提前规划监控告警、故障处置、容灾备份体系，为系统运行提供保障；

（4）部署架构（系统组网拓扑）承接技术架构与运维架构，将逻辑组件映射到服务器、网络等物理资源，明确组网关系，作为实施部署的直接依据；

（5）项目架构覆盖所有架构：业务规则设计、产品原型绘制、应用接口开发、第三方对接调试、数据流转配置、技术扩容部署、运维体系落地，全都要被拆成项目任务。

一句话总结这条链：业务定目标，产品转需求，集成通外部，应用搭系统，数据管信息，技术打底座，运维保运行，部署落物理，项目来落地。

四、关于技术和业务的思考

判断一个架构好不好，也不用听一堆术语，问三个问题就够了：

• 业务目标有没有被逐层承接？

• 数据和技术底座能不能撑住业务场景？

• 设计能不能被拆成任务，按期交付？

技术复杂度，永远由业务场景复杂度决定。看懂这条链，你就看懂了软件架构的底层逻辑，怎么来学习技术架构。避免一直关注技术，忽视了业务的复杂度和深度才是决定技术的源头。

软件架构系列文章说明：

AI 时代，推测未来的软件工程只需要两类人：拥有产品审美的Creative Builders（创意构建者）和擅长破解系统复杂性的 Deep System Experts（深度系统专家）。软件架构，就是典型的系统难题之一。随着AI 编码生产力的飞速提升，可持续演进、能快速适应业务变化的架构变得至关重要。我打算借助费曼学习法，通过输出来复盘、沉淀过往架构经验。

九篇分篇规划：

参考书目：

1.演进式架构（Building Evolutionary Architectures）[美] 尼尔·福特（Neal Ford）、[美] 丽贝卡·帕森斯（Rebecca Parsons）、[澳] 帕特里克·柯（Patrick Kua）；第2版新增作者普拉莫德·萨达拉奇（Pramod Sadalage）

2.持续架构实践（Continuous Architecture in Practice）[美] 穆拉特·埃尔德（Murat Erder）、[美] 皮埃尔·普约尔（Pierre Pureur）、[英] 伊恩·伍兹（Eoin Woods）

3.架构师修炼之道（Design It! From Programmer to Software Architect）[美] 迈克尔·基林（Michael Keeling）

4.面向模式的软件体系结构（POSA，Pattern-Oriented Software Architecture）[德] Frank Buschmann、Regine Meunier、Hans Rohnert、[瑞士] Peter Sommerlad、[德] Michael Stal（卷1）

5.企业应用架构模式（Patterns of Enterprise Application Architecture，EAA）[英] 马丁·福勒（Martin Fowler）（David Rice、Matthew Foemmel等参与贡献）

6.整洁架构之道（Clean Architecture）[美] 罗伯特·C·马丁（Robert C. Martin，Bob大叔）

7.浮现式设计（Emergent Design：专业软件开发的演进本质）[美] Scott L. Bain（斯科特·贝恩）

8.架构思维：从程序员到CTO郭东白（美籍华人）

9.左耳听风：传奇程序员练级攻略（博文视点出版，陈皓文集）

10.架构的本质（极客时间《许式伟的架构课》）