企业官网建设流程全解析

假设你是一个写了三五年业务代码的后端工程师，日常 CRUD 得心应手，搜索引擎也玩得明白，但某天评审会上，技术负责人突然问你：“你这个系统的架构是什么？为什么订单模块和支付模块要这样分？”你发现自己只能说“我们用了微服务”“RPC 就完事了”这类话。这不是少数人的困境，而是很多后端开发者的共同痛点：代码能力不差，架构设计能力却一直停留在“看别人的架构图点头”的水平。

这里我想先给出一个明确判断：架构设计不是少数天才的灵感，也不完全依赖“十年经验自然就会”。它是一套可以拆解、训练和显式化的技能体系。所谓技能，意味着你不需要等某种顿悟，而是可以通过流程、模板、检查清单和真实项目训练，稳定地产出合格的架构设计。这也是为什么现在很多团队开始把“架构设计”本身沉淀成可复用的文档模板、决策记录，甚至 Agent Skill。

这篇文章会从概念、技能树、完整工作流程、订单系统示例、架构评审、常见误区到团队落地，把“架构设计技能”这件事讲透。文章很长，建议先收藏再慢慢看。读完你可以得到三样东西：一张告诉你要练什么的技能树、一套可以直接复制的文档和决策模板、一份能拿去评审自己设计的检查清单。

1. 为什么“架构设计”是一项技能，而不是天赋

很多开发者对架构设计的认知是：先写好几年代码，然后某一天“开窍”了，突然就能画架构图了。这种认知很危险，因为它把一个可以被系统训练的能力，归类成了不可复制的个人天赋。

技能的基本特征是“可分解、可学习、可训练、可评估”。架构设计完全满足这四个条件。拆开来看，一次架构设计由几个环节组成：理解业务目标、识别约束条件、抽象系统边界、设计模块划分、选型技术方案、权衡质量属性、记录决策过程。每一个环节都有对应的方法论，都可以单独训练。例如“识别约束条件”可以练：成本上限是多少、团队多少人、吞吐量预期是多少、合规要求有哪些、现有系统能复用多少。把这些问句列出来，就是一份检查清单。清单不会让你一夜成为架构大师，但会把你做架构设计的下限抬得很高。

为什么很多人仍然觉得架构设计难？因为架构设计的“结果”往往是图或者 PPT，真正重要的“过程”——决策和取舍——是看不见的。老手看一眼需求就知道要拆几个服务，是因为他们在过去几千个项目里反复衡量过“拆或不拆”的代价，这些判断被压缩成了直觉。但直觉背后依然是一层层显式的问题，比如“数据一致性要求有多高”“团队协作边界在哪里”“故障爆炸半径能不能接受”“部署和发布频率是否跟得上”。新手如果能一层层问出这些问题，产出的设计质量并不会差太多。这正是“技能化”的意义：把高手脑内压缩的判断，还原成显式的步骤和问题，让更多人能够执行。

所以本文的核心观点是：架构设计 = 在不确定条件下做有记录的权衡决策。注意两个关键词。第一是“不确定”，架构师永远不可能拿到完整信息才开始设计，必须学会带着假设推进；第二是“有记录”，只做决策不记录理由，设计就没有生命力，后来者无法演进，只能推翻重来。

2. 架构设计的核心概念与技能树

在讨论具体流程之前，先统一几个核心概念。这些概念会贯穿后续的示例和评审清单。

2.1 软件架构是什么

软件架构是系统的重要组件及其相互关系，以及影响这些关系设计和演进的原则。通俗讲，架构不仅决定了系统里有哪些模块，更决定了这些模块之间怎么通信、质量属性如何保证、未来如何演进。一个系统没有架构是不可能的，哪怕是“一坨代码直接堆在 controller 里”，也是一种架构，只是这种架构是在无意识中长出来的，没人对它负责罢了。

2.2 质量属性：架构设计的标尺

架构设计的好坏不是靠感觉，而是靠质量属性。常见质量属性包括：性能、可用性、可扩展性、安全性、可维护性、可测试性、成本。任何架构方案都在这些属性之间做权衡。例如微服务提升了可扩展性和团队自治，但牺牲了运维复杂度与分布式事务成本。没有了质量属性作为标尺，“架构好坏”就变成了纯主观争论。

2.3 架构风格：不要为了拆分而拆分

架构风格是常见问题的一套预定义解决方案。理解几种主流风格，能帮助你在设计时快速生成候选方案：

这里特别想提醒一点：微服务只是架构风格的一种，不是架构设计的目标。如果团队只有一二十人、业务模型还在快速变化、发布频率并不高，模块化单体通常是比微服务更稳妥的选择。这个判断在后文的订单系统示例中会再次出现。

2.4 C4 模型：统一大家的架构视图

C4 模型把架构视图分成四个层次：Context（系统上下文）、Container（容器/进程/应用）、Component（组件）、Code（代码）。很多团队架构讨论低效，是因为讨论 Context 层的人在讲“我们系统之间怎么调用”，而听众在思考 Component 层的类怎么放。C4 的价值是让团队先约定“现在讨论的是哪一层”，避免鸡同鸭讲。后续实战示例会给出 Context 层的绘制示例。

2.5 ADR：记录架构决策为什么这么做

ADR（Architecture Decision Record，架构决策记录）是一种轻量级的决策文档。一个 ADR 通常包含背景、决策、备选方案、后果。它解决的核心问题是：几个月后或者换人后，团队仍然知道“为什么当初这么选”。没有 ADR 的架构文档，最后一定会退化成“现状说明书”，只能告诉大家系统长什么样，却说不清为什么长成这样。

2.6 架构设计技能树

综合以上概念，可以画出一张架构设计技能树：

1. 需求抽象：从模糊的业务描述里提取功能范围、质量属性和约束。
2. 边界识别：划分系统内部和外部，确定协作关系。
3. 技术选型：评估不同中间件、框架、语言是否匹配当前约束。
4. 模块设计：定义模块边界、依赖方向和接口契约。
5. 质量设计：考虑性能、可用性、安全、可观测性的落地手段。
6. 文档与评审：把决策显式化，并能让他人验证。

技能树的每个叶子，都可以用对应的模板和清单来训练。下面我们就按这个技能树，走一遍完整的架构设计流程。

3. 架构设计的完整工作流程

架构设计不应该从画图开始，而应该从澄清问题开始。很多失败的架构设计，问题都出在第一步：需求还没对齐，就开始画高深的架构图。这里给出一套比较通用的六步流程。

3.1 第一步：澄清目标与约束

开工前先问一组问题：

• 这次设计的业务目标是什么？要支撑什么增长或者解决什么现状问题？
• 硬性约束有哪些？预算、时间、团队规模、第三方依赖？
• 质量属性指标是多少？例如 QPS、可用性 SLA、响应时间 P99。
• 有没有必须遵守的合规或安全要求？

这一步的产出是“一句话目标 + 约束清单”。如果约束不明确，后续所有决策都可能是空中楼阁。

3.2 第二步：识别干系人与系统上下文

明确谁在跟这个系统交互：用户、运营人员、外部系统、下游依赖。画出 Context 图。这个步骤的作用是确定系统的外部边界，避免把所有外部系统都当成系统内部的一部分。很多人画架构图一上来就开始画内部模块，其实应该先确定外面那一圈边界。

3.3 第三步：生成候选设计

基于需求和边界，至少给出两个候选方案，而不是只拿着一个方案去评审。候选方案可以来自不同的架构风格组合。比如“单体重构” vs “模块化单体” vs “微服务拆分”。每个方案都要说明：它满足了哪些质量属性，在哪些方面表现较弱。

3.4 第四步：权衡与决策

把候选方案放进一个评估表里，按质量属性逐项打分或者做优劣分析，最后选择一个最适合当前约束的方案。注意“最适合”不等于“技术上最先进”。成本、团队能力、时间窗口都是决策变量。决策时用 ADR 把理由记录下来。

3.5 第五步：形成设计文档与契约

只画图不够，还需要把设计落成可读的文档和契约。包括：C4 图、模块清单、接口契约、数据流、异常链路、部署架构。其中接口契约建议直接写成 OpenAPI 或 protobuf，让生成代码和文档共用同一份定义，避免文档和代码分家。

3.6 第六步：评审与演进

架构设计不是一次性活动。评审通过、代码落地后，还需要持续检查“实际代码是否还符合设计”，以及“当初的假设是否失效”。这需要有常规的架构评审机制和 ADR 沉淀。没有演进的架构文档，就是很快腐烂的存档。

这套六步流程本身，就是可训练、可复制的技能载体。一个人哪怕经验不足，只要严格走完流程、产出对应模板，也能做出值得评审的架构方案。

4. 从需求到架构：一个订单系统的设计过程

为了让上面的流程更具体，这里设计一个常见场景：电商团队要建设“订单中心”，负责下单、支付回调、履约、售后等能力。现状是一个老单体应用里已经揉进了订单、商品、库存、支付等逻辑，随着业务增长，发布越来越难，团队间开始互相踩代码，老板希望解决协作和扩展问题。

需求看起来很清楚，但架构设计必须把模糊需求转成具体约束。我们先做 4.1 到 4.4 的推演，再在下一章给出具体文档产物。

4.1 需求与约束识别

从业务描述里能提取出的功能范围：

• 用户可创建订单、取消订单、查看订单详情。
• 支付成功或失败后，订单状态需要更新。
• 支付成功后，需要向仓储侧下发履约单。
• 运营人员可查询订单并处理售后。

关键质量属性和约束：

• 目标 QPS 并不高，日均订单量数十万量级。
• 可用性要求较高，订单不能丢失，但允许短暂延迟。
• 团队规模仅两个后端小组，约十几人，当前没有专职运维团队。
• 老系统已经在生产运行，必须平滑迁移。
• 订单金额相关操作需要考虑审计和数据一致性。

从这些约束能明显感觉到：团队规模不大，业务复杂度中等，吞吐压力有限。此时首选微服务架构其实风险偏高。

4.2 系统上下文建模

我们把系统外部的角色列出来：

• 消费者：通过商城前端下单。
• 运营人员：查询订单、处理售后。
• 支付网关：外部支付能力。
• 仓储中心：接收履约单。
• 消息中心：发送短信和站内信。

系统上下文很清晰，订单系统在中间，外部跟这些角色打交道。这一步不需要考虑内部怎么拆分，先确定边界。

4.3 生成候选方案

根据约束，可以提出三个候选方案：

方案 A：继续单体，不做拆分，只优化分层。优点：改动最小、风险最低。缺点：团队协作问题没解决，发布冲突依旧，无法满足后续多团队分工。

方案 B：模块化单体。将订单、支付、库存等逻辑按业务模块隔离，模块间通过内部接口调用，仍然是一个进程一个部署单元。优点：复杂度可控，协作边界清楚，所需基础设施变化小。缺点：模块边界维护需要纪律，无法独立扩缩容，物理隔离不够。

方案 C：直接微服务拆分。按订单、支付、履约等服务拆成多个独立部署单元。优点：独立发布、独立伸缩、服务边界强。缺点：分布式事务、服务发现、日志链路、监控体系、容器编排、运维成本都需要补齐，对两个小团队压力大。

4.4 权衡与决策

在这个假设场景里，更稳妥的判断是：选择方案 B，模块化单体作为第一阶段架构。核心原因是约束中的“团队规模小、无专职运维、需要平滑迁移”。先通过模块边界解决协作问题，沉淀好领域模型和接口契约，等业务和团队规模达到一定阈值后，再按边界逐步把模块拆成独立服务。这种“先收紧边界，再物理拆分”的路径，比直接上微服务稳健得多。

5. 完整示例：架构设计文档与决策记录

上一章是推演过程，这一章给出可以直接复制用于自己项目的产物模板。这些产物都围绕“模块化单体”方案展开。

5.1 上下文图（C4 Model / PlantUML 示例）

C4 的 Context 层用于描述系统与外界的边界。以下是一个可复制的 PlantUML 骨架，渲染后的图可以作为架构设计文档的第一张图。

@startuml order-context title 订单中心系统上下文 actor 消费者 actor 运营人员 rectangle 订单中心 { usecase "创建订单" as UC_CREATE usecase "订单状态变更" as UC_STATUS usecase "订单查询" as UC_QUERY usecase "售后处理" as UC_AFTER_SALE } rectangle 支付网关 rectangle 仓储中心 rectangle 消息中心 消费者 --> UC_CREATE 消费者 --> UC_QUERY 运营人员 --> UC_QUERY 运营人员 --> UC_AFTER_SALE UC_CREATE ..> 支付网关 : 发起支付 UC_STATUS <.. 支付网关 : 支付结果回调 UC_STATUS ..> 仓储中心 : 下发履约单 UC_STATUS ..> 消息中心 : 发送通知 @enduml

图中最重要的是表达系统与外部依赖之间的关系。评审时可以先看这张图：系统边界是否清楚、外部依赖是否齐全。很多人把上下文图画成了内部模块图，这是最常见的错误。

5.2 架构决策记录 ADR 示例

ADR 的价值在于记录决策理由。下面是一份完整示例，可以直接放入团队仓库的docs/adr/目录。

# ADR-0001：订单中心第一阶段采用模块化单体架构 - 状态：已接受 - 日期：2025-01-15 - 决策者：张三、李四、王五 ## 背景 订单中心需要从老单体中拆分演进，目标是改善团队协作、 降低发布冲突，并为后续业务扩展保留空间。 当前团队规模为两个后端小组约 15 人，没有专职运维团队， 生产系统要求平滑迁移。 ## 决策 第一阶段采用“模块化单体”架构： - 保持单个部署单元，避免过早引入分布式基础设施。 - 在代码层面严格划分订单、支付、履约、售后等业务模块。 - 模块之间只允许通过应用层接口调用，禁止直接访问内部仓储。 - 采用领域驱动设计（DDD）的战术模式定义模块边界。 ## 备选方案 1. 直接微服务拆分：可提供更强的独立伸缩与发布能力， 但需要投入服务发现、链路追踪、日志聚合、容器编排等基础设施， 团队规模与运维成本不允许。 2. 完全单体不分层：迁移成本最低，但无法解决团队协作冲突， 也不利于后续演进。 ## 后果 - 好处：协作边界更清晰，发布风险可控，不需要重写系统。 - 代价：模块化边界需要长期维护，编译期约束不足， 必须通过架构测试保证模块依赖方向不反向。 - 演进路径：当订单模块流量或团队规模达到预设阈值时， 可优先将订单模块拆分为独立服务，再逐步迁移其他模块。

注意 ADR 中必须有“备选方案”和“后果”。没有备选方案，ADR 就不是决策记录，而是公告；“后果”则让后来者知道这个决策付出的成本是什么。

5.3 接口契约示例（OpenAPI）

接口契约是模块间协作的“法律”。建议在模块化单体阶段就把接口用 OpenAPI 定义好。以下是最小示例，定义订单创建的请求响应结构。

openapi: 3.0.3 info: title: Order Service API version: 1.0.0 paths: /orders: post: summary: 创建订单 requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/CreateOrderRequest' responses: '200': description: 下单成功 content: application/json: schema: $ref: '#/components/schemas/CreateOrderResponse' '400': description: 参数错误或库存不足 components: schemas: CreateOrderRequest: type: object required: - userId - items properties: userId: type: string items: type: array items: $ref: '#/components/schemas/OrderItem' OrderItem: type: object required: - skuId - quantity properties: skuId: type: string quantity: type: integer minimum: 1 CreateOrderResponse: type: object properties: orderId: type: string status: type: string enum: - CREATED - REJECTED - PENDING_PAYMENT

接口契约的好处在于：模块之间只依赖契约，不依赖实现细节。后续即使要把订单模块拆成独立服务，HTTP 协议和数据结构都不需要大改。

5.4 模块代码结构示例（DDD 分层）

模块化单体的关键是代码结构必须“物理可见”。如果只是口头上说模块化，代码还是随便放，那等于没有边界。以下是一个可参考的 Java 工程结构：

order-center/ ├── order-application/ # 应用层：用例编排、事务边界 ├── order-domain/ # 领域层：订单核心模型、业务规则、领域服务 ├── order-infrastructure/ # 基础设施层：数据库、消息、外部 RPC ├── order-interfaces/ # 接口层：HTTP Controller、事件消费者 ├── payment-application/ ├── payment-domain/ ├── payment-infrastructure/ └── payment-interfaces/

这里的关键规则是依赖方向：interfaces 依赖 application，application 依赖 domain，domain 不依赖任何外部框架和基础设施。如果发现 domain 里出现了 JPA 注解或者 RPC 调用，说明模块边界已经被破坏了。可以在 CI 中加入依赖分析工具，自动拦截依赖反向。

5.5 运行与验证方式

这些架构设计产物如何验证？分三层看。

第一层，图能不能渲染、文档是否放进了仓库。用 PlantUML 渲染：

plantuml -tsvg order-context.puml

如果本机没有命令，可以安装对应插件或者使用在线渲染工具。重点不是渲染工具本身，而是让图成为仓库中可维护的代码资产。

第二层，ADR 是否完整、决策是否能被团队理解。建议组织一次 30 分钟的架构评审，让不参与编码的同事也能根据 ADR 复述出“为什么选模块化单体”。

第三层，接口契约是否可用。可以用 OpenAPI 生成 mock server，或者用契约测试工具校验实现是否满足契约。契约测试的目的是：就算订单模块还没有拆出去，接口变化也会被尽早发现。

6. 如何验证一个架构设计是“好”的

很多团队的架构评审最后都变成“各说各话”，因为没有统一标准。实际上，好架构设计至少满足四个条件：可验证的质量属性、清晰的演进路径、团队能理解并执行、决策原因有记录。下面展开讲。

6.1 看质量属性是否可验证

如果设计文档里写“系统要高性能”，那等于没说。要写“下单接口 P99 小于 200ms”“订单状态最终一致，消息延迟不超过 1 分钟”。只有指标明确，才能在设计阶段判断是否可行，也才能在事后验证。

6.2 看是否有演进路径

架构设计不是终点，而是起点。好的设计一定回答了这个问题：如果未来某个假设失效，怎么演进？例如 ADR-0001 里写清楚了“当订单模块流量或团队规模达到预设阈值时，可优先拆分订单模块”，这就是演进路径。一个不能演进的设计，本质上是在透支未来。

6.3 看团队能否理解并执行

再漂亮的架构图，如果团队没人能讲清楚模块边界和依赖规则，代码落地时一定会跑偏。可以做一个简单的验证：随机找两个开发，请他们画一遍系统模块图和依赖方向。如果两个人画得基本一致，说明设计沟通有效；如果差异很大，问题不在开发者，在文档。

6.4 看决策是否有记录

评审时检查：每个关键方案选择是否都有 ADR？ADR 里有没有备选方案和后果？如果一个系统里到处是“技术人员拍脑袋定的”又没有任何记录，架构就会快速腐烂。

6.5 架构评审检查清单示例

为了让评审落地，可以准备一份 YAML 格式的检查清单，随架构文档一起提交：

# 文件路径：docs/architecture-review-checklist.yaml checks: - id: REQ-001 name: 功能范围与约束 question: 文档是否列出了功能范围、硬性约束和非功能指标？ required: true - id: CTX-001 name: 系统上下文 question: 上下文图是否包含了所有外部角色与依赖系统？ required: true - id: ALT-001 name: 候选方案 question: 是否至少评估了两个候选方案，并说明了各自取舍？ required: true - id: ADR-001 name: 决策记录 question: 每个关键决策是否有对应ADR，且包含备选方案与后果？ required: true - id: MOD-001 name: 模块边界 question: 模块清单是否清楚，依赖方向是否绘制并约定？ required: true - id: API-001 name: 接口契约 question: 跨模块接口是否已有契约定义？ required: true - id: OBS-001 name: 可观测性 question: 日志、指标、链路追踪是否在设计中被考虑？ required: true

这份清单不是形式主义，而是把架构评审从“主观感受”变成“核对项”。评审不通过的原因会非常具体，例如“没有列出备选方案”“上下文图缺少支付网关”，而不是“我觉得这个设计不行”。

7. 常见架构设计误区与排查思路

在项目里，很多架构问题并不是孤立的，而是反复出现的模式。下面整理成一张表格，方便对照排查。

这里最想强调的是第一行。很多团队在规模不够时强行微服务化，结果不是架构先进，而是把问题复杂度从业务层转移到了运维层。从材料看，这种“为了微服务而微服务”的情况在中小团队里其实非常普遍。排查时先看数据：服务数量、发布频率、人均维护服务数、线上故障恢复时长。如果服务很多但发布频率和恢复能力都很差，问题往往不是拆分力度不够，而是拆过了头。

8. 架构设计技能的团队落地与 AI 辅助

个人掌握了架构设计技能还不够，真正的工程价值在于把这项技能变成团队的常规能力。这里给出几条落地建议。

8.1 模板先行，让文档产出标准化

团队统一的 ADS（架构设计说明书）模板、ADR 模板、评审清单模板，是所有后续实践的基础。新模块设计、技术选型、系统拆分，都要求按模板产出对应文档。模板会让新人也敢于做架构设计，因为他们有清晰的流程可以依赖。

8.2 文档即代码，进入评审流程

架构文档不要放在 Wiki 或者共享盘，而是放进代码仓库的docs/目录，与代码一起走 MR/PR 评审。这样每次改动架构文档都有记录，评审意见可追溯，也容易与代码变更对照。ADR 建议按编号递增存放，例如docs/adr/ADR-0001-modular-monolith.md。

8.3 用架构测试和契约测试守护边界

模块化单体最大的风险是边界腐化。可以通过 CI 中的依赖检查工具禁止跨模块直连，用契约测试确保接口实现不偏离定义。把检查前置到 CI，才能保证架构设计在代码层面真正被执行。

8.4 把架构设计流程沉淀为 Skill

架构设计经验一旦显式化为流程、提示词和检查清单，就可以打包成团队可复用的“技能资产”。如果你所在团队正在使用具备 Skill 能力的 AI Agent 辅助开发，可以把“先架构设计再写代码”的理念做成一个 Skill 定义。下面是一个通用化的 YAML 示例，表达的是流程控制思路，具体平台接入方式以你的工具文档为准。

# 文件路径：skills/architecture-design-skill/skill.yaml name: architecture-design-skill description: > 在产出代码之前，先完成架构设计澄清与约束识别。 适用于新模块设计、系统拆分、技术选型评审等场景。 version: 1.0.0 workflow: - step: clarify_goal_and_constraints prompt: | 请先识别本次设计的目标、功能范围、硬性约束和非功能指标， 输出一句话目标与约束清单。 - step: identify_stakeholders_and_context prompt: | 列出系统涉及的主要角色与外部系统，描述系统上下文边界。 - step: generate_candidate_designs prompt: | 基于需求生成至少2个候选方案，说明每个方案在质量属性上的取舍。 - step: document_adr prompt: | 使用ADR模板记录最终决策、备选方案和决策后果。 checklist: - 是否识别了必须满足的质量属性 - 是否至少评估了两个候选方案 - 是否说明了否决备选方案的原因 - 模块依赖方向是否清晰 - 是否包含演进路径或回滚方案

这个 Skill 示例的核心价值是“先澄清，再设计，最后记录”，而不是让 AI 直接代替人做决策。在架构设计这件事上，AI 更适合扮演“生成候选方案的助手”和“检查清单的执行者”，而最终决策、责任和风险判断仍然必须由人来做。尤其是涉及数据一致性、生产环境迁移等高风险决策时，AI 的输出只能作为参考，不能替代评审。

8.5 定期复盘架构假设

每个 ADR 里都隐含了当时做判断的假设，而这些假设可能在未来失效。建议团队每季度或每半年做一次“ADR 体检”，检查哪些决策仍然成立，哪些假设已经变化。这一步能让架构设计保持活力，而不是变成一堆历史文档。

9. 总结与后续学习方向

架构设计这项能力，真正值得投入的训练不是“看更多架构图”，而是在真实项目里把一次设计从口头讨论变成有记录的文档、经过评审并落地执行。你可以从很小的事情开始：挑一个最近正在设计或重构的小模块，花一两个小时写一份 ADR，记录背景、备选方案、决策和后果。再对照评审清单检查一遍，你会发现很多此前没有意识到的盲区。

如果你想继续深入学习，可以从这几个方向延伸：领域驱动设计（DDD）用来练模块边界识别；C4 Model 练架构视图表达；ATAM 等架构权衡分析方法练质量属性评估；架构适应度函数（Architecture Fitness Functions）练如何用自动化手段保护架构规则。这些方法论都不是孤立的，最终都会回到本文反复强调的那句话：架构设计的关键，是在不确定条件下做出有记录、可演进、能被团队执行的权衡决策。

先在一个小项目里把流程跑通，比等待“经验足够丰富”更有效。下一份架构文档，从一份 ADR 开始。