假设你是一个写了三五年业务代码的后端工程师日常 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记录架构决策为什么这么做ADRArchitecture Decision Record架构决策记录是一种轻量级的决策文档。一个 ADR 通常包含背景、决策、备选方案、后果。它解决的核心问题是几个月后或者换人后团队仍然知道“为什么当初这么选”。没有 ADR 的架构文档最后一定会退化成“现状说明书”只能告诉大家系统长什么样却说不清为什么长成这样。2.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 权衡与决策维度方案A 单体方案B 模块化单体方案C 微服务团队协作改善弱中强部署发布效率弱中强运维成本低低高分布式事务风险无内部事务高迁移风险低中高技术演进空间弱中强强在这个假设场景里更稳妥的判断是选择方案 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 依赖 applicationapplication 依赖 domaindomain 不依赖任何外部框架和基础设施。如果发现 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 看决策是否有记录评审时检查每个关键方案选择是否都有 ADRADR 里有没有备选方案和后果如果一个系统里到处是“技术人员拍脑袋定的”又没有任何记录架构就会快速腐烂。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. 常见架构设计误区与排查思路在项目里很多架构问题并不是孤立的而是反复出现的模式。下面整理成一张表格方便对照排查。问题现象可能原因排查方式解决方案服务拆了很多线上故障率更高团队规模撑不起多服务运维统计服务数量、发布频率、人均维护服务数收缩边界先减少服务数或改模块化单体架构文档和代码完全对不上文档只在设计阶段维护后续无人更新抽查文档中的模块图与代码结构是否一致把文档放进代码仓库评审 PR 时同步更新模块化单体渐渐退化成大泥球没有架构测试约束依赖方向用依赖分析工具查看模块间引用加入 CI 检查禁止跨模块直接访问仓储用了很新的技术栈但没人能维护选型只看了技术先进性没评估团队能力线上问题响应时长、熟悉该技术的人数选型前先做团队能力盘点和学习成本评估没人知道当初为什么这么设计缺少 ADR 决策记录检查关键节点是否有 ADR 和评审记录补写关键 ADR以后新决策强制记录每次评审都在争论同一层问题没有约定 C4 视图层级看评审材料是否标注了当前层评审前明确讨论 Context / Container / Component 哪一层演进到一半发现边界切错了一开始没分析业务变更频率和团队归属回顾拆服务后每次需求改动涉及几个服务用事件风暴或业务能力地图重新识别边界这里最想强调的是第一行。很多团队在规模不够时强行微服务化结果不是架构先进而是把问题复杂度从业务层转移到了运维层。从材料看这种“为了微服务而微服务”的情况在中小团队里其实非常普遍。排查时先看数据服务数量、发布频率、人均维护服务数、线上故障恢复时长。如果服务很多但发布频率和恢复能力都很差问题往往不是拆分力度不够而是拆过了头。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 开始。
架构设计不是天赋：一套可复制的技能树与实践方法
假设你是一个写了三五年业务代码的后端工程师日常 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记录架构决策为什么这么做ADRArchitecture Decision Record架构决策记录是一种轻量级的决策文档。一个 ADR 通常包含背景、决策、备选方案、后果。它解决的核心问题是几个月后或者换人后团队仍然知道“为什么当初这么选”。没有 ADR 的架构文档最后一定会退化成“现状说明书”只能告诉大家系统长什么样却说不清为什么长成这样。2.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 权衡与决策维度方案A 单体方案B 模块化单体方案C 微服务团队协作改善弱中强部署发布效率弱中强运维成本低低高分布式事务风险无内部事务高迁移风险低中高技术演进空间弱中强强在这个假设场景里更稳妥的判断是选择方案 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 依赖 applicationapplication 依赖 domaindomain 不依赖任何外部框架和基础设施。如果发现 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 看决策是否有记录评审时检查每个关键方案选择是否都有 ADRADR 里有没有备选方案和后果如果一个系统里到处是“技术人员拍脑袋定的”又没有任何记录架构就会快速腐烂。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. 常见架构设计误区与排查思路在项目里很多架构问题并不是孤立的而是反复出现的模式。下面整理成一张表格方便对照排查。问题现象可能原因排查方式解决方案服务拆了很多线上故障率更高团队规模撑不起多服务运维统计服务数量、发布频率、人均维护服务数收缩边界先减少服务数或改模块化单体架构文档和代码完全对不上文档只在设计阶段维护后续无人更新抽查文档中的模块图与代码结构是否一致把文档放进代码仓库评审 PR 时同步更新模块化单体渐渐退化成大泥球没有架构测试约束依赖方向用依赖分析工具查看模块间引用加入 CI 检查禁止跨模块直接访问仓储用了很新的技术栈但没人能维护选型只看了技术先进性没评估团队能力线上问题响应时长、熟悉该技术的人数选型前先做团队能力盘点和学习成本评估没人知道当初为什么这么设计缺少 ADR 决策记录检查关键节点是否有 ADR 和评审记录补写关键 ADR以后新决策强制记录每次评审都在争论同一层问题没有约定 C4 视图层级看评审材料是否标注了当前层评审前明确讨论 Context / Container / Component 哪一层演进到一半发现边界切错了一开始没分析业务变更频率和团队归属回顾拆服务后每次需求改动涉及几个服务用事件风暴或业务能力地图重新识别边界这里最想强调的是第一行。很多团队在规模不够时强行微服务化结果不是架构先进而是把问题复杂度从业务层转移到了运维层。从材料看这种“为了微服务而微服务”的情况在中小团队里其实非常普遍。排查时先看数据服务数量、发布频率、人均维护服务数、线上故障恢复时长。如果服务很多但发布频率和恢复能力都很差问题往往不是拆分力度不够而是拆过了头。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 开始。
