Arch Day 119: 作品集整理 — 120天架构修炼的完整展示

日期: 2026-07-27 (Day 119) 阶段: 第四阶段 - 高阶融合 标签: #作品集 #求职 #职业发展

---

概述

今天是120天架构修炼计划的倒数第二天。回头看，我们用118天积累了海量的架构文档、设计方案、面试答案和系统设计。但这些散落在笔记里的知识碎片，如果不经过系统整理和有针对性的展示，面试官永远看不到你的全貌。

作品集不是"把文件摆上去"，而是讲一个故事：你从哪来、你会什么、你能解决什么问题。

本篇将完成三件事：

1. 盘点——120天所有产出的分类清单
2. 设计——针对不同受众（求职/晋升/咨询）的作品集结构
3. 执行——从 GitHub 仓库、技术博客到 LinkedIn，全链路落地

---

一、120天全部架构产出盘点

1.1 四个阶段总览

120天架构修炼 — 产出全景图
━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 1: 架构基础 (Day 1-30)
├── 30篇学习笔记
├── 15个ADR (架构决策记录)
├── 10道面试题及答案
├── 2篇案例分析 (蚂蚁金服/Stripe)
└── 1个 Phase 总结

Phase 2: 金融域深度 (Day 31-65)
├── 35篇领域笔记
├── 20个ADR (核心银行/支付/风控/交易)
├── 20道面试题及答案
├── 4篇案例分析 (Thought Machine/微众银行/Stripe支付/蚂蚁风控)
├── 3个系统设计方案 (核心银行选型/跨境支付/AML)
└── 1个 Phase 总结

Phase 3: 零售域深度 (Day 66-95)
├── 30篇领域笔记
├── 15个ADR (商品/库存/订单/供应链)
├── 15道面试题及答案
├── 3篇案例分析 (淘宝/Shopify/瑞幸)
├── 2个系统设计方案 (秒杀/数仓)
└── 1个 Phase 总结

Phase 4: 高阶融合 (Day 96-120)
├── 25篇高阶笔记
├── 10个ADR (云原生/AI/治理)
├── 20道面试题及答案 (4大面试专题)
├── 2篇案例分析 (云金融/AI平台)
├── 5个系统设计 (支付/秒杀/核心银行/风控/全渠道)
└── 2个终极总结 (Day 119-120)

1.2 13篇架构分析文章清单

1.3 60+ 设计文档清单（按领域分类）

金融域设计文档 (25+)

零售域设计文档 (25+)

通用架构设计文档 (10+)

1.4 60+ 面试题及答案

按主题分类：

每道题均包含：

• 30秒版本（电梯演讲，核心论点）
• 2分钟版本（结构化回答，含架构图）
• 追问准备（2-3个追问及深度回答）

1.5 5个完整系统设计

---

二、作品集结构设计

2.1 受众分析：不同目的，不同展示

作品集不是一份文档，而是一套针对不同受众的"武器库"

受众1: 求职（应聘架构师岗位）
├── 核心诉求: 证明你能做架构决策、能落地
├── 展示重点: 系统设计 + 案例分析 + 面试答案
├── 媒介: GitHub仓库 + 技术博客 + 简历
└── 关键: 要有可运行的代码 + 有深度的文章

受众2: 晋升（内部晋升高级架构师/技术VP）
├── 核心诉求: 证明你有全局视野、能影响技术方向
├── 展示重点: 架构治理框架 + 技术债管理 + 架构评审方法
├── 媒介: 内部Wiki + 技术分享PPT + 架构评审报告
└── 关键: 要体现对业务的理解和组织影响力

受众3: 咨询（以顾问身份输出架构能力）
├── 核心诉求: 证明你有行业经验、能快速产出价值
├── 展示重点: 行业方案模板 + ADR库 + 案例库
├── 媒介: 方案模板库 + 白皮书 + 演讲/培训材料
└── 关键: 要有可复用的框架和清晰的方法论

2.2 求职版作品集结构

这是最重要的版本，按面试流程倒推结构：

架构师求职作品集
├── README.md (2分钟读完，让人决定要不要继续看)
│   ├── 一句话自我定位
│   ├── 核心差异化 (10年金融零售 × Web3 × AI增强)
│   ├── 作品集导航 (带超链接的目录)
│   └── 联系方式
│
├── /system-designs/ (面试必考)
│   ├── payment-system.md (支付系统设计)
│   ├── flash-sale-system.md (秒杀系统设计)
│   ├── core-banking-system.md (核心银行系统设计)
│   ├── risk-control-system.md (实时风控系统设计)
│   └── omnichannel-retail.md (全渠道零售系统设计)
│
├── /case-studies/ (体现思考深度)
│   ├── ant-financial-evolution.md
│   ├── stripe-payment-philosophy.md
│   ├── thought-machine-cloud-native.md
│   ├── taobao-monolith-to-platform.md
│   └── luckin-digital-transformation.md
│
├── /architecture-decisions/ (体现决策能力)
│   ├── ADR-index.md (ADR索引)
│   └── /adrs/ (精选10个ADR)
│
├── /architecture-diagrams/ (体现表达能力)
│   ├── c4-models/ (C4分层架构图)
│   ├── archimate/ (企业架构图)
│   └── wardley-maps/ (战略态势图)
│
├── /interview-prep/ (面试速查)
│   ├── business-architecture-qa.md
│   ├── software-architecture-qa.md
│   ├── financial-architecture-qa.md
│   └── retail-architecture-qa.md
│
└── /methodology/ (体现方法论)
    ├── architecture-review-checklist.md
    ├── adr-template.md
    └── my-architecture-methodology.md

2.3 晋升版作品集结构

内部晋升材料
├── 架构治理成果
│   ├── 架构治理框架设计 (Day 103)
│   ├── 技术债量化与治理方案 (Day 27 + 105)
│   ├── 架构评审流程优化 (Day 21)
│   └── ADR制度推行成果
│
├── 技术方向影响力
│   ├── 云原生迁移路线图 (Day 96-102)
│   ├── AI平台建设规划 (Day 107-109)
│   ├── 遗留系统现代化方案 (Day 104)
│   └── 架构演进路线图
│
├── 跨部门协作
│   ├── 架构沟通方法论 (Day 26)
│   ├── 技术决策透明化 (ADR制度)
│   └── 康威定律与组织架构匹配 (Day 106)
│
└── 人才培养
    ├── 架构评审导师制
    ├── 技术分享记录
    └── 团队架构能力提升计划

2.4 咨询版作品集结构

架构咨询能力展示
├── 行业方案库
│   ├── 金融行业架构方案模板
│   ├── 零售行业架构方案模板
│   └── 跨行业通用架构模式
│
├── 方法论工具箱
│   ├── 架构评估方法 (ATAM/CBAM)
│   ├── 业务能力建模方法
│   ├── 技术债评估框架
│   └── 云迁移评估框架
│
├── 案例库 (脱敏)
│   ├── 核心银行选型咨询
│   ├── 电商平台架构评审
│   └── 数字化转型路线图
│
└── 培训课程
    ├── 《架构思维入门》大纲
    ├── 《DDD实战》大纲
    └── 《金融架构师养成》大纲

---

三、ADR 精选集 — 最有代表性的10个ADR

ADR（Architecture Decision Record）是架构师最核心的产出物之一。以下精选10个ADR，覆盖不同决策类型：

ADR精选索引

ADR展示建议

每个ADR在作品集中建议使用以下精简格式：

# ADR-001: 核心银行选型

## 背景
公司计划替换运行15年的核心银行系统，当前系统无法支撑...

## 决策
选择云原生核心银行平台（Thought Machine Vault类方案）

## 备选方案
| 方案 | 优势 | 劣势 | 成本 |
|------|------|------|------|
| 传统外购 | 成熟稳定 | 定制困难、升级慢 | 高 |
| 完全自研 | 完全可控 | 周期长、风险大 | 很高 |
| 云原生平台 | 灵活、API-First | 供应商依赖 | 中 |

## 后果
- 正面: 产品迭代速度提升3倍，API集成成本降低60%
- 负面: 团队需6个月学习曲线，供应商锁定风险需要抽象层缓解
- 风险缓解: 定义核心抽象接口，保持可替换性

## 状态: 已采纳 (2026-05)

---

四、架构图集 — 精选20+

架构图是架构师的"第二语言"。以下按类型整理精选图集：

4.1 C4模型图集 (8张)

4.2 ArchiMate企业架构图集 (5张)

4.3 BPMN流程图集 (4张)

4.4 Wardley Map战略图集 (5张)

架构图展示建议

展示原则：
1. 每张图配50-100字说明（为什么画这张图、解决什么问题）
2. 使用一致的绘图工具和样式（推荐 Structurizr DSL + PlantUML）
3. 图片清晰度要高（SVG优先，PNG至少300DPI）
4. C4模型保持分层一致（不要跳层级）
5. 避免信息过载——一张图聚焦一个故事

---

五、GitHub仓库组织

5.1 推荐目录结构

architecture-portfolio/
├── README.md                      # 作品集首页（最重要）
├── METHODOLOGY.md                 # 个人架构方法论
│
├── system-designs/                # 系统设计（面试核心）
│   ├── README.md                  # 设计索引
│   ├── payment-system/
│   │   ├── README.md              # 设计说明
│   │   ├── diagrams/              # 架构图
│   │   └── adr/                   # 相关ADR
│   ├── flash-sale-system/
│   ├── core-banking-system/
│   ├── risk-control-system/
│   └── omnichannel-retail/
│
├── case-studies/                   # 案例分析
│   ├── README.md
│   ├── ant-financial.md
│   ├── stripe.md
│   ├── thought-machine.md
│   ├── taobao.md
│   └── luckin.md
│
├── architecture-decisions/         # ADR库
│   ├── README.md                   # ADR索引+模板
│   ├── adr-001-core-banking.md
│   ├── adr-002-payment-consistency.md
│   └── ...
│
├── diagrams/                       # 架构图集
│   ├── c4/
│   ├── archimate/
│   ├── bpmn/
│   └── wardley-maps/
│
├── interview-prep/                 # 面试准备
│   ├── business-architecture.md
│   ├── software-architecture.md
│   ├── financial-architecture.md
│   └── retail-architecture.md
│
├── domain-knowledge/               # 领域知识精华
│   ├── finance/
│   │   ├── core-banking-essentials.md
│   │   ├── payment-architecture.md
│   │   └── risk-control.md
│   └── retail/
│       ├── ecommerce-essentials.md
│       ├── supply-chain.md
│       └── omnichannel.md
│
└── templates/                      # 可复用模板
    ├── adr-template.md
    ├── system-design-template.md
    ├── architecture-review-checklist.md
    └── tech-debt-assessment.md

5.2 README.md 关键内容

# 🏗️ Architecture Portfolio

## 关于我
10年金融零售产品+技术经验 | 全栈架构能力 | 金融 × 零售 × AI

## 核心差异化
- **金融领域深度**: 核心银行、支付、风控全链路架构经验
- **零售领域广度**: 从商品到供应链、从电商到全渠道
- **AI增强架构**: 大模型时代的架构设计方法论
- **Web3视野**: DeFi/RWA的架构理解

## 作品导航
| 类别 | 数量 | 推荐阅读 |
|------|------|---------|
| 系统设计 | 5个 | [支付系统](link) / [风控系统](link) |
| 案例分析 | 13篇 | [蚂蚁金服](link) / [Stripe](link) |
| ADR | 10+个 | [核心银行选型](link) |
| 架构图集 | 20+张 | [C4模型集](link) |
| 面试题库 | 60+题 | [金融架构面试](link) |

## 技术栈
Architecture: TOGAF / ArchiMate / C4 Model / DDD / Event Storming
Diagrams: Structurizr / PlantUML / Mermaid
Analysis: Dune SQL / Python

5.3 GitHub仓库优化建议

仓库优化清单：

1. 标签(Tags)管理
   ├── 领域标签: #finance #retail #supply-chain
   ├── 类型标签: #system-design #case-study #adr #interview
   ├── 技术标签: #microservice #event-driven #cqrs #cloud-native
   └── 难度标签: #beginner #intermediate #advanced

2. GitHub Pages 部署
   ├── 使用 MkDocs 或 Docusaurus 生成静态站
   ├── 自定义域名 (如 arch.yourname.com)
   └── 自动化部署 (GitHub Actions)

3. 持续更新
   ├── 每月至少更新1篇新内容
   ├── 保持commit频率（展示持续学习）
   └── 及时更新过时的技术描述

4. 互动设计
   ├── 开启 Discussions 接受提问
   ├── 欢迎 Issue 指出错误
   └── 鼓励 Star 和 Fork

---

六、个人技术博客/网站展示策略

6.1 博客定位

定位公式：[你的独特背景] × [架构视角] × [具体领域]

例如：
"金融零售老兵的架构修炼手记"
"10年PM转型架构师：从业务到技术的桥梁"
"金融+零售+AI：全栈架构师的跨域实践"

6.2 内容策略

发表平台矩阵：

内容金字塔：

                    ┌─────────────┐
                    │  旗舰文章    │ ← 深度案例分析 (季度1篇)
                    │  (5000+字)  │   发表在InfoQ/Medium
                    ├─────────────┤
                   │  专题系列     │ ← 系统设计/领域知识 (月2篇)
                   │  (3000字)    │   发表在掘金/公众号
                  ├───────────────┤
                 │  实践分享       │ ← 具体技术实践 (周1篇)
                 │  (1500字)      │   发表在掘金/公众号
                ├─────────────────┤
               │  短观点/评论      │ ← 行业评论、快速分析 (日更)
               │  (100-500字)     │   发表在Twitter/LinkedIn
              └───────────────────┘

6.3 博客系列规划

推荐系列（基于120天积累，可直接提炼发表）：

---

七、简历中如何展示架构能力

7.1 不同岗位的简历版本

版本A：首席架构师 / 解决方案架构师

核心展示：
├── 强调: 全局架构能力 + 跨域经验 + 技术战略
├── 弱化: 具体编码细节
└── 关键词: TOGAF, Enterprise Architecture, Solution Design

项目经验写法示例：
"主导核心银行系统架构选型与迁移规划，评估3种方案(传统外购/自研/
云原生)，最终选定云原生方案，预计TCO降低40%、产品迭代速度提升
3倍。产出完整ADR文档集和18个月迁移路线图。"

版本B：技术VP / CTO

核心展示：
├── 强调: 技术战略 + 组织影响力 + 业务价值
├── 弱化: 技术细节
└── 关键词: Technical Strategy, Team Building, Business Impact

项目经验写法示例：
"制定公司技术架构3年演进路线图，推动从单体到微服务的架构转型。
建立架构治理委员会和ADR制度，技术决策透明度提升80%。主导技术
债量化评估，识别并排期偿还高优先级债务12项。"

版本C：架构咨询顾问

核心展示：
├── 强调: 行业经验 + 方法论 + 快速交付
├── 弱化: 单一公司经历
└── 关键词: Consulting, Framework, Best Practice, Industry Knowledge

项目经验写法示例：
"为3家中型银行提供核心系统现代化咨询，交付包含架构评估报告、
目标架构设计、迁移路线图和风险缓解方案的完整交付物集。平均
项目周期8周，客户满意度评分4.8/5。"

7.2 简历中的架构能力关键词

分层展示架构能力：

战略层:
  Enterprise Architecture | TOGAF | Wardley Mapping |
  Technology Strategy | Architecture Governance

业务层:
  Business Capability Modeling | Value Stream Mapping |
  Domain-Driven Design | Event Storming | BIAN Framework

应用层:
  Microservices | Event-Driven Architecture | CQRS |
  API Design (REST/gRPC/GraphQL) | Saga Pattern

数据层:
  Data Architecture | CQRS | Event Sourcing |
  Real-time Streaming (Kafka/Flink) | Data Governance

基础设施层:
  Cloud-Native | Kubernetes | Service Mesh |
  Observability | Chaos Engineering

领域层:
  Core Banking | Payment Systems | Risk Management |
  E-commerce | Supply Chain | Omnichannel Retail

新兴技术:
  AI/ML Platform | LLM Integration | Web3/DeFi |
  RWA | Account Abstraction

7.3 简历量化指标参考

架构师简历的量化指标应覆盖四个维度：

1. 规模指标
   - 系统峰值QPS：XX万/秒
   - 管理数据量：XX TB
   - 服务用户数：XX万/XX亿
   - 团队规模：XX人

2. 效率指标
   - 系统可用性：99.99%
   - 接口响应时间：P99 < XXms
   - 发布频率：从月发到日发
   - 迁移周期：XX个月完成XX个服务迁移

3. 成本指标
   - TCO降低XX%
   - 运维人力减少XX%
   - 资源利用率提升XX%

4. 业务指标
   - 产品迭代速度提升XX%
   - 故障恢复时间从XX小时缩短到XX分钟
   - 支撑业务增长XX倍

---

八、LinkedIn优化建议

8.1 Profile优化

Headline (标题):
  ❌ "架构师"
  ✅ "Solutions Architect | 10yr Finance & Retail | Core Banking + Payment + Risk"
  ✅ "Enterprise Architect | Financial Services | AI-Enhanced Architecture"

About (摘要) 结构:
  1. 一句话定位 (Who am I)
  2. 核心差异化 (Why me)
  3. 领域专长 (What I know)
  4. 当前关注 (What's next)
  5. CTA (How to reach me)

Experience 描述原则:
  - 每段经历用 "Context → Action → Result" 结构
  - 量化成果（见7.3节）
  - 突出架构决策而非执行细节
  - 使用英文关键词（便于猎头搜索）

8.2 LinkedIn内容策略

内容类型及频率：

周一: 行业洞察 (金融/零售科技趋势)
周三: 架构实践 (技术干货、设计思考)
周五: 职业成长 (学习心得、转型思考)

内容格式：
├── 短文 (300-500字): 占60% — 观点+论据+CTA
├── 长文 (1000+字): 占20% — 深度分析、案例解读
├── 转发评论: 占15% — 行业新闻+自己观点
└── Poll投票: 占5% — 引发讨论、提高互动

8.3 Networking策略

目标人脉圈层：

第一圈 (直接价值):
├── 目标公司的hiring manager
├── 同岗位架构师 (peer networking)
└── 猎头/HR (金融科技/零售科技方向)

第二圈 (间接价值):
├── 技术博主/KOL
├── 开源社区活跃贡献者
└── 行业会议演讲者

互动方式：
├── 主动评论他人帖子 (有价值的评论，非"赞同")
├── 分享时@相关人 (适度，不spam)
├── 私信介绍自己+具体价值 (非群发模板)
└── 参加线上/线下技术活动后主动connect

---

九、开源贡献策略

9.1 开源贡献路径

阶段1: 文档贡献 (最低门槛)
├── 修复技术文档的错误/过时内容
├── 翻译文档 (英→中 或 中→英)
├── 补充使用示例
└── 目标项目: Structurizr, PlantUML, ArchiMate工具

阶段2: 工具贡献 (中等门槛)
├── 开发架构相关的小工具/插件
│   ├── ADR管理CLI工具
│   ├── C4模型验证器
│   └── 架构fitness function框架
├── 为现有工具贡献feature
└── 目标: 自己的开源项目积累Star

阶段3: 标准贡献 (高门槛/高价值)
├── 参与TOGAF/ArchiMate标准讨论
├── 在OpenGroup/BIAN社区提交反馈
└── 发布行业参考架构模板

9.2 推荐贡献的开源项目

---

十、实操：整理完整作品集

10.1 整理步骤

Step 1: 盘点 (今天上午)
━━━━━━━━━━━━━━━━━━━
□ 列出120天所有文档清单
□ 标注每篇文档的质量等级 (A/B/C)
□ 识别缺失或需要补充的内容
□ 标注可以直接对外展示的 vs 需要脱敏/优化的

Step 2: 分类 (今天下午-1)
━━━━━━━━━━━━━━━━━━━━━
□ 按本文第五节的目录结构建立文件夹
□ 将A级文档复制到对应目录
□ B级文档标注"待优化"
□ C级文档暂不放入作品集

Step 3: 精炼 (今天下午-2)
━━━━━━━━━━━━━━━━━━━━━━
□ 为每个系统设计写100字摘要
□ 为每篇案例分析写50字导读
□ 为每个ADR提取"一句话决策"
□ 确保所有架构图清晰、有图例

Step 4: 组装 (今天晚上)
━━━━━━━━━━━━━━━━━━━━━
□ 编写 README.md (作品集首页)
□ 编写 METHODOLOGY.md (个人方法论)
□ 配置 GitHub Pages 或 MkDocs
□ 检查所有链接是否有效
□ 邀请1-2位朋友review

Step 5: 发布 (明天)
━━━━━━━━━━━━━━━━━━
□ GitHub仓库设为Public
□ LinkedIn更新Profile，添加项目链接
□ 发第一篇LinkedIn帖子介绍作品集
□ 在掘金/Medium发文宣传

10.2 质量检查清单

作品集质量自检：

□ README能在2分钟内让人理解你的能力范围
□ 每篇系统设计都有清晰的"问题→方案→权衡"结构
□ 架构图有图例、有说明、分辨率足够
□ ADR格式统一、决策理由清晰
□ 没有错别字、格式问题
□ 没有敏感信息（公司名、客户名、具体数据已脱敏）
□ 所有链接可点击且有效
□ 有个人联系方式（邮箱/LinkedIn）
□ 在手机端也能正常阅读
□ 至少让一个人帮你审阅过

---

十一、面试题

题目 1：介绍一个你最自豪的架构设计？

30秒版本

我最自豪的是一个实时风控系统的架构设计。核心挑战是在100ms内完成包含500+条规则的风险评估，同时保证可解释性（监管要求）。我设计了"规则引擎+ML模型"的混合架构：规则引擎处理明确的黑白名单和阈值规则，ML模型处理行为模式识别，两者的结果通过决策融合层汇总。最终系统P99延迟控制在80ms内，误报率从15%降到3%，同时满足了监管对可解释性的要求。

2分钟版本

背景：公司的风控系统面临三重挑战——业务增长导致交易量翻倍、新型欺诈手段层出不穷、监管对风控决策的可解释性要求越来越高。原有的纯规则系统规则膨胀到2000+条，维护成本极高，且无法检测新型欺诈。

我的架构设计：

实时风控混合架构
┌─────────────────────────────────────────────────┐
│                   接入层                          │
│  交易事件 → 特征提取 → 规则引擎 + ML模型 → 决策  │
├─────────────────────────────────────────────────┤
│                                                   │
│  特征平台:                                        │
│  ├── 实时特征 (Flink计算, <100ms)                 │
│  ├── 近实时特征 (5min窗口聚合)                    │
│  └── 离线特征 (T+1用户画像)                       │
│                                                   │
│  规则引擎 (处理确定性规则):                        │
│  ├── 黑名单命中 → 直接拒绝                        │
│  ├── 阈值规则 (金额/频率/地理异常)                 │
│  └── 组合规则 (多条件组合)                         │
│                                                   │
│  ML模型 (处理模式识别):                            │
│  ├── 行为序列模型 (LSTM)                          │
│  ├── 设备指纹模型 (XGBoost)                       │
│  └── 图关系模型 (GNN, 近实时)                     │
│                                                   │
│  决策融合层:                                       │
│  ├── 规则结果 + ML评分 → 加权融合                  │
│  ├── 可解释性: 每个决策附带Top3影响因子             │
│  └── 灰度策略: 新模型先observation后enforcement   │
│                                                   │
└─────────────────────────────────────────────────┘

关键决策和权衡：

1. 为什么不全用ML：监管要求可解释性，纯ML的"黑箱"无法满足。规则引擎处理可解释的部分，ML补充模式识别能力。
2. 为什么不全用规则：规则膨胀难以维护，且无法应对未知欺诈模式。2000条规则精简到500条核心规则，其余用ML替代。
3. 特征平台为什么分三层：不同特征的时效性要求不同。实时特征（如"最近5分钟交易次数"）用Flink流计算；离线特征（如"用户近30天行为画像"）用批处理，T+1更新。

成果：P99延迟80ms（目标100ms），误报率从15%降到3%，规则维护成本降低60%，新型欺诈检出率提升40%。

追问准备

追问: "如何保证ML模型更新不影响线上稳定性？"

采用"灰度发布+AB测试"策略。新模型先部署到Shadow模式（只观察不决策），观察7天的预测准确率和性能指标。通过后进入灰度阶段（1%→10%→50%→100%流量），每个阶段至少运行3天。同时保留回滚能力——如果新模型异常，30秒内切回旧模型。

追问: "这个架构最大的妥协是什么？"

最大的妥协是复杂度。混合架构意味着要维护两套系统（规则引擎+ML平台），团队需要同时具备规则配置能力和机器学习能力。我们通过建立平台团队（负责ML基础设施）和业务团队（负责规则配置）的分工来缓解，但跨团队沟通成本确实增加了。

---

题目 2：你的架构方法论是什么？

30秒版本

我的架构方法论可以概括为"三步走"：第一步，理解业务——用业务能力建模和价值流分析确保架构对齐业务目标；第二步，做出决策——用ADR记录每个关键决策的背景、备选方案和权衡理由；第三步，持续验证——用架构适应度函数和ATAM评审确保架构演进方向正确。核心信念是：好的架构不是一次设计出来的，而是在约束中持续演进的。

2分钟版本

我的架构方法论: "理解 → 决策 → 验证" 循环

┌──────────────────────────────────────────────┐
│                                                │
│   1. 理解业务 (Why & What)                     │
│   ├── 业务能力建模 → 识别核心域/支撑域/通用域   │
│   ├── 价值流分析 → 找到价值交付的瓶颈            │
│   ├── Wardley Map → 判断组件的演化阶段           │
│   ├── 利益相关方分析 → 明确约束和期望             │
│   └── 产出: 业务上下文、约束清单、质量属性优先级  │
│                                                │
│            ↓                                   │
│                                                │
│   2. 做出决策 (How)                             │
│   ├── 架构风格选择 (决策树)                      │
│   ├── 核心模式选择 (DDD/EDA/CQRS/Saga等)        │
│   ├── 技术选型评估 (CBAM经济分析)                │
│   ├── ADR记录 (每个关键决策)                     │
│   └── 产出: 架构方案、C4图、ADR集                │
│                                                │
│            ↓                                   │
│                                                │
│   3. 持续验证 (Feedback)                        │
│   ├── ATAM架构评审 (上线前)                      │
│   ├── 适应度函数 (自动化守护)                    │
│   ├── 技术债量化 (持续跟踪)                      │
│   ├── 架构治理委员会 (组织保障)                   │
│   └── 产出: 评审报告、债务清单、演进路线图        │
│                                                │
│            ↓ (循环)                              │
│                                                │
│   回到1: 业务变化 → 重新理解 → 调整决策           │
│                                                │
└──────────────────────────────────────────────┘

五个核心信念：

1. 架构为业务服务——不存在脱离业务的"好架构"。选微服务还是单体，取决于组织规模、交付速度需求和团队能力，不取决于技术趋势。

2. 决策比方案重要——架构师的核心输出不是PPT和图，而是ADR。清晰记录"为什么这样选、放弃了什么、接受了什么代价"，比画一张完美的架构图重要10倍。

3. 约束是设计的一部分——监管要求、团队能力、预算限制、历史债务，这些"限制"不是架构设计的障碍，而是架构设计的输入。好的架构师不是忽略约束追求完美，而是在约束中找到最优解。

4. 演进优于设计——不要试图设计一个"永远正确"的架构。设计一个"容易改变"的架构更重要。这意味着：低耦合、清晰的接口边界、渐进式迁移能力。

5. 沟通和技术同等重要——再好的架构方案，如果利益相关方不理解、团队不认同，就无法落地。架构师需要在不同层级（CEO到开发者）用不同语言传达同一个架构故事。

追问准备

追问: "你的方法论和TOGAF有什么区别？"

TOGAF是一个全面的企业架构框架，它定义了架构开发方法（ADM）的完整生命周期。我的方法论是在TOGAF的基础上做了两个简化：一是更加聚焦在"决策记录"（ADR）而非完整的架构文档集；二是引入了Wardley Map做战略分析，这是TOGAF中相对薄弱的部分。可以说，我的方法论是TOGAF + ADR + Wardley Map的实用主义组合。

追问: "在时间紧迫的项目中，你会跳过哪些步骤？"

我不会跳过"理解业务"和"ADR记录"，这两个是底线。可以简化的是：ATAM评审可以缩减为轻量级架构walkthrough（1小时而非1天）；架构文档可以先写ADR+C4 Context图，不需要完整的arc42文档；Wardley Map可以用简单的Buy/Build/Partner决策替代。但关键决策的记录不能省——因为你现在省的时间，将来会以10倍的沟通成本还回来。

---

总结

作品集整理不是一天的工作，而是一个持续优化的过程。今天的核心目标是：

1. 完成盘点和分类——知道自己有什么
2. 建立展示结构——知道怎么展示
3. 启动发布流程——迈出第一步

记住：最好的作品集不是最全的，而是最能讲清楚"你是谁、你能做什么"的。 宁可只展示5个精品系统设计，也不要堆砌50篇未经打磨的笔记。

明天是最后一天——Day 120。我们将完成能力自评、知识图谱绘制、求职策略规划，以及写给自己的一封信。120天的架构修炼之旅，到了画上句号的时刻。