什么是架构：顶层设计、模块、组件与三大原则

“架构”这个词经常被说得很大，但如果把它拆开看，本质其实很朴素：架构就是软件系统的顶层结构，以及围绕这套结构所做的设计取舍。

它不是炫技，也不是画图比赛。架构的真实任务，是帮助团队在复杂度上升时，仍然能够把系统组织得清晰、可演化、可交付。

架构到底是什么

原始笔记里给了几个容易混淆的概念：

这个区分很重要，因为它决定了你在讨论时到底在讨论什么。

flowchart LR
    A["系统"] --> B["模块"]
    A --> C["组件"]
    B --> D["业务职责划分"]
    C --> E["技术复用单元"]
    A --> F["顶层结构 = 架构"]

模块更偏逻辑视角，组件更偏物理视角。

这也是为什么一个系统可以在设计层面被拆成几个模块，但在工程实现上未必每个模块都对应一个独立部署单元。

订单系统里，Order、Payment、Inventory 可以是三个模块；但它们不一定要一开始就做成三个服务。先把边界想清楚，比先拆部署更重要。

框架关注的是“怎么用”；架构关注的是“怎么组织”。

csharp

// 伪代码：框架帮助你落地能力，架构决定你怎么组合这些能力
builder.Services.AddControllers();
builder.Services.AddScoped<IOrderService, OrderService>();

如果说框架是“工具箱”，架构更像是“施工蓝图”。两者都重要，但不是一回事。

架构设计的真正目的 这份笔记非常直接：架构设计主要是为了解决软件系统复杂度带来的问题。

这句话看似简单，但非常关键。因为它意味着：

合适优于业界领先。

架构没有绝对优劣，只有是否适合当前阶段。对一个团队很合适的方案，对另一个团队可能是灾难。

简单优于复杂。

复杂不是能力，复杂通常是问题。能用简单方案解决的，就不要提前堆过多抽象。

演化优于一步到位。

软件不是建筑，不能指望一次设计就一劳永逸。业务会变，团队会变，技术栈也会变，所以架构必须预留演进空间。

flowchart TD
    A["合适"] --> B["简单"]
    B --> C["演化"]
    C --> D["持续适应业务变化"]

这三条原则不是口号，而是一组互相制衡的判断方式：

因此，架构师真正要做的不是追求某种“最先进形态”，而是在当前约束下做最合适的组合。

从机器语言、汇编语言、高级语言，到结构化程序设计和面向对象，架构的演进史其实就是软件复杂度不断上升、工程方法不断回应复杂度的历史。

timeline
    title 架构与软件复杂度的演进
    1940 年前 : 机器语言
    1940 年代 : 汇编语言
    1950 年代 : 高级语言
    1960-1970 年代 : 结构化程序设计与第一次软件危机
    1980 年代 : 面向对象与第二次软件危机