senior-architect

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Senior Architect

高级架构师

Overview

概述

Provide architecture-level guidance for system design decisions. This skill produces Architecture Decision Records (ADRs), trade-off analyses, scalability blueprints, and non-functional requirements specifications. Every recommendation includes explicit trade-offs and is grounded in proven patterns.

Announce at start: "I'm using the senior-architect skill for system design and architecture decisions."

为系统设计决策提供架构层面的指导。本技能可产出架构决策记录（ADR）、权衡分析、可扩展性蓝图和非功能需求规格说明。所有建议均包含明确的权衡说明，并基于经过验证的架构模式。

开始时声明： "我将使用高级架构师技能来处理系统设计和架构决策相关问题。"

Phase 1: Requirements Analysis

第一阶段：需求分析

Goal: Capture all functional and non-functional requirements before designing.

目标： 在设计前收集所有功能和非功能需求。

Actions

执行动作

Identify functional requirements (capabilities)
Define non-functional requirements (quality attributes)
Identify constraints (budget, team, timeline, compliance)
Map integration points with existing systems
Establish success criteria and SLOs

识别功能需求（系统能力）
定义非功能需求（质量属性）
明确约束条件（预算、团队、时间线、合规要求）
梳理与现有系统的集成点
制定成功标准和SLO

STOP — Do NOT proceed to Phase 2 until:

停止 — 满足以下条件前请勿进入第二阶段：

Functional requirements are listed
Non-functional requirements are quantified (not vague)
Constraints are explicit
Success criteria are measurable

已列出所有功能需求
非功能需求已量化（无模糊描述）
约束条件已明确
成功标准可衡量

Phase 2: Architecture Design

第二阶段：架构设计

Goal: Evaluate options and select the approach with the best trade-off profile.

目标： 评估多种方案，选择权衡最优的实现路径。

Actions

执行动作

Evaluate architectural styles (monolith, microservices, event-driven)
Design component boundaries and interfaces
Define data architecture (storage, flow, consistency)
Plan infrastructure and deployment topology
Address cross-cutting concerns (auth, logging, monitoring)

评估架构风格（单体、微服务、事件驱动）
设计组件边界和接口
定义数据架构（存储、流转、一致性）
规划基础设施和部署拓扑
处理横切关注点（认证、日志、监控）

Architecture Style Decision Table

架构风格决策表

Factor	Monolith	Modular Monolith	Microservices	Serverless
Team size < 10	Preferred	Strong fit	Overkill	Good for bursty
Team size > 30	Challenging	Good	Preferred	Depends
Domain well-understood	Good fit	Good fit	Not needed yet	Good fit
Domain evolving rapidly	Fine to start	Good fit	Too early	Good fit
Need independent deployment	Not possible	Limited	Key benefit	Built-in
Operational maturity low	Good fit	Good fit	High risk	Managed risk
Variable/bursty load	Over-provisioned	Over-provisioned	Possible	Strong fit

评估因素	单体架构	模块化单体	微服务	Serverless
团队规模 < 10	首选	非常适配	过度设计	适合突发负载场景
团队规模 > 30	实施难度高	适配	首选	视场景而定
领域已非常清晰	适配	适配	暂不需要	适配
领域快速迭代	适合起步	非常适配	为时过早	适配
需要独立部署	不支持	有限支持	核心优势	原生支持
运维成熟度低	适配	适配	高风险	风险可控
负载可变/突发	资源过度供给	资源过度供给	可适配	非常适配

Default Recommendation

默认建议

Start with Modular Monolith: clear module boundaries, single deployment. Extract to microservices only when you have proven need for independent scaling, deployment, or team autonomy.

优先选择模块化单体：模块边界清晰，仅需单次部署。仅当你明确需要独立扩缩容、独立部署或团队自治需求时，再拆分到微服务架构。

Trade-Off Analysis: Common Pairs

权衡分析：常见配对

Improving	May Degrade
Consistency	Availability, Latency
Performance	Maintainability, Cost
Security	Usability, Performance
Scalability	Simplicity, Cost
Flexibility	Performance, Complexity
Time to Market	Quality, Scalability

提升项	可能劣化项
一致性	可用性、延迟
性能	可维护性、成本
安全性	易用性、性能
可扩展性	简洁性、成本
灵活性	性能、复杂度
上线速度	质量、可扩展性

Decision Matrix Template

决策矩阵模板

Weight each quality attribute (1-5), score each option (1-5), multiply and sum.

| Quality Attribute  | Weight | Option A | Option B | Option C |
|--------------------|--------|----------|----------|----------|
| Performance        |   4    |  4 (16)  |  3 (12)  |  5 (20)  |
| Maintainability    |   5    |  5 (25)  |  4 (20)  |  2 (10)  |
| Scalability        |   3    |  3 (9)   |  5 (15)  |  4 (12)  |
| Cost               |   4    |  4 (16)  |  2 (8)   |  3 (12)  |
| Total              |        |    66    |    55    |    54    |

Weight each quality attribute (1-5), score each option (1-5), multiply and sum.

| Quality Attribute  | Weight | Option A | Option B | Option C |
|--------------------|--------|----------|----------|----------|
| Performance        |   4    |  4 (16)  |  3 (12)  |  5 (20)  |
| Maintainability    |   5    |  5 (25)  |  4 (20)  |  2 (10)  |
| Scalability        |   3    |  3 (9)   |  5 (15)  |  4 (12)  |
| Cost               |   4    |  4 (16)  |  2 (8)   |  3 (12)  |
| Total              |        |    66    |    55    |    54    |

STOP — Do NOT proceed to Phase 3 until:

停止 — 满足以下条件前请勿进入第三阶段：

At least 2 architectural options have been evaluated
Trade-offs are explicitly documented
Decision matrix scores support the recommendation
Data architecture is defined

已评估至少2种架构方案
所有权衡已明确记录
决策矩阵得分支持最终推荐方案
数据架构已明确定义

Phase 3: Documentation and Validation

第三阶段：文档和验证

Goal: Record decisions and validate against requirements.

目标： 记录决策并对照需求验证设计合理性。

Actions

执行动作

Write Architecture Decision Records for key decisions
Create system context and container diagrams (C4 model)
Validate against non-functional requirements
Identify risks and mitigation strategies
Define evolutionary architecture guardrails

为核心决策编写架构决策记录（ADR）
绘制系统上下文和容器图（C4模型）
对照非功能需求验证设计
识别风险和缓解策略
定义演进式架构护栏

ADR Format

ADR格式

markdown

undefined

markdown

undefined

ADR-{number}: {Title}

Status

Proposed | Accepted | Deprecated | Superseded by ADR-{number}

Context

What is the issue motivating this decision?

Decision

What change are we proposing?

Consequences

Positive

[Benefit 1]
[Benefit 2]

[Benefit 1]
[Benefit 2]

Negative

[Trade-off 1]
[Trade-off 2]

[Trade-off 1]
[Trade-off 2]

Risks

[Risk and mitigation]

[Risk and mitigation]

Alternatives Considered

Option	Pros	Cons	Verdict
Option A	...	...	Chosen
Option B	...	...	Rejected because...

undefined

Option	Pros	Cons	Verdict
Option A	...	...	Chosen
Option B	...	...	Rejected because...

undefined

C4 Model Levels

C4模型层级

Level	Shows	When to Use
Level 1: System Context	Users and external systems	Always
Level 2: Container	Major technical building blocks	Always
Level 3: Component	Components within containers	Complex services
Level 4: Code	Class-level detail	Critical/complex areas only

层级	展示内容	使用场景
层级1：系统上下文	用户和外部系统	所有场景
层级2：容器	核心技术构建块	所有场景
层级3：组件	容器内部的组件	复杂服务场景
层级4：代码	类级别细节	仅关键/复杂模块

STOP — Documentation complete when:

停止 — 满足以下条件时文档视为完成：

ADRs written for all key decisions
System context diagram created
NFRs validated against design
Risks documented with mitigations

所有核心决策都已编写ADR
已创建系统上下文图
设计已通过非功能需求验证
风险已记录并对应缓解方案

Scalability Patterns

可扩展性模式

Horizontal Scaling Decision Table

水平扩缩容决策表

Pattern	Use When	Implementation
Load Balancing	Multiple instances of same service	Round-robin, least connections, IP hash
Stateless Services	Need to add/remove instances freely	JWT/external session store
Auto-scaling	Variable load patterns	CPU/memory/request-rate triggers
Read Replicas	Read-heavy workloads	Route reads to replicas, writes to primary

模式	使用场景	实现方式
负载均衡	同一服务运行多个实例	轮询、最少连接、IP哈希
无状态服务	需要自由增减实例	JWT/外置会话存储
自动扩缩容	负载模式可变	CPU/内存/请求速率触发
只读副本	读密集型工作负载	读请求路由到副本，写请求走主库

Sharding Strategy Decision Table

分库分表策略决策表

Strategy	How	Good For
Hash-based	Consistent hash of key	Even distribution
Range-based	Date range, ID range	Time-series data
Geographic	By region/country	Data locality
Tenant-based	Per customer	Multi-tenant SaaS

策略	实现方式	适用场景
哈希分片	键的一致性哈希	均匀分布需求
范围分片	日期范围、ID范围	时间序列数据
地理分片	按地区/国家划分	数据就近访问需求
租户分片	按客户划分	多租户SaaS

Caching Layers

缓存层级

Client Cache (browser) -> CDN Cache -> API Gateway Cache ->
Application Cache (Redis) -> Database Query Cache -> Database

Client Cache (browser) -> CDN Cache -> API Gateway Cache ->
Application Cache (Redis) -> Database Query Cache -> Database

Non-Functional Requirements Template

非功能需求模板

markdown

undefined

markdown

undefined

Performance

Response time: p95 < 200ms, p99 < 500ms for API calls
Throughput: 1000 RPS sustained, 5000 RPS peak
Batch processing: 1M records/hour

Response time: p95 < 200ms, p99 < 500ms for API calls
Throughput: 1000 RPS sustained, 5000 RPS peak
Batch processing: 1M records/hour

Availability

Target: 99.9% (8.76h downtime/year)
RTO (Recovery Time Objective): < 15 minutes
RPO (Recovery Point Objective): < 5 minutes

Target: 99.9% (8.76h downtime/year)
RTO (Recovery Time Objective): < 15 minutes
RPO (Recovery Point Objective): < 5 minutes

Scalability

Current: 10K DAU
12-month target: 100K DAU
Scale dimension: users, data volume, request rate

Current: 10K DAU
12-month target: 100K DAU
Scale dimension: users, data volume, request rate

Security

Authentication: OAuth 2.0 / OIDC
Authorization: RBAC with resource-level permissions
Data encryption: at rest (AES-256) and in transit (TLS 1.3)

Authentication: OAuth 2.0 / OIDC
Authorization: RBAC with resource-level permissions
Data encryption: at rest (AES-256) and in transit (TLS 1.3)

Observability

Logging: structured JSON, 30-day retention
Metrics: RED method, custom business metrics
Tracing: distributed tracing across all services
Alerting: PagerDuty integration, tiered severity

undefined

Logging: structured JSON, 30-day retention
Metrics: RED method, custom business metrics
Tracing: distributed tracing across all services
Alerting: PagerDuty integration, tiered severity

undefined

SLO/SLA/SLI Framework

SLO/SLA/SLI框架

Term	Definition	Example
SLI	Measurable metric	Request latency, error rate
SLO	Target value	99.9% availability
SLA	Contractual commitment	99.5% with penalty clause
Error Budget	1 - SLO	0.1% = 8.76h/year

术语	定义	示例
SLI	可衡量指标	请求延迟、错误率
SLO	目标值	99.9%可用性
SLA	合同承诺	99.5%可用性附带惩罚条款
错误预算	1 - SLO	0.1% = 每年8.76小时容错时间

Anti-Patterns / Common Mistakes

反模式/常见错误

Anti-Pattern	Why It Is Wrong	Correct Approach
Resume-driven architecture	Complexity without benefit	Choose simplest solution that works
Distributed monolith	All downsides of both	Either true monolith or true microservices
Premature optimization	Scaling for 1M users with 100	Design for current + 10x, not 1000x
Golden hammer	One technology for everything	Right tool for each problem
Architecture without validation	Untested assumptions	Load test, failure test, validate
Big upfront design without iteration	Requirements change	Evolutionary architecture with guardrails
Vague NFRs ("fast", "scalable")	Cannot be validated	Quantified targets with measurement

反模式	问题点	正确做法
简历驱动架构	无意义的复杂度提升	选择能满足需求的最简单方案
分布式单体	同时具备两种架构的所有缺点	要么做真正的单体，要么做真正的微服务
过早优化	只有100个用户就为100万用户做扩容	设计支撑当前+10倍规模即可，不需要考虑1000倍
golden hammer	所有问题都用同一个技术解决	为每个问题选择最合适的工具
未经验证的架构	全是未测试的假设	做压测、故障测试、验证设计
一次性的大规模前置设计无迭代	需求会发生变化	带护栏的演进式架构
模糊的非功能需求（"快"、"可扩展"）	无法验证	带衡量方式的量化目标

Subagent Dispatch Opportunities

子Agent调度场景

Task Pattern	Dispatch To	When
Analyzing different architecture layers	`Agent` tool with `subagent_type="Explore"` (one per layer)	When reviewing frontend, backend, and infra independently
Security assessment of architecture	`Agent` tool invoking `security-review` skill	When architecture involves auth, data flow, or external APIs
Performance implications analysis	`Agent` tool invoking `performance-optimization` skill	When architecture decisions affect latency or throughput
Code quality review of existing patterns	`Agent` tool dispatching `code-reviewer` agent	When evaluating current codebase for refactoring

Follow the

dispatching-parallel-agents

skill protocol when dispatching.

任务模式	调度目标	触发时机
分析不同架构层	`Agent` 工具， `subagent_type="Explore"` （每层一个）	需要独立审核前端、后端和基础设施时
架构安全评估	`Agent` 工具调用 `security-review` 技能	架构涉及认证、数据流或外部API时
性能影响分析	`Agent` 工具调用 `performance-optimization` 技能	架构决策会影响延迟或吞吐量时
现有模式代码质量审核	`Agent` 工具调度 `code-reviewer` agent	评估现有代码库重构需求时

调度时遵循

dispatching-parallel-agents

技能协议。

Integration Points

集成点

Skill	Relationship
`senior-backend`	Backend implementation follows architecture decisions
`senior-fullstack`	Full-stack architecture follows service boundaries
`security-review`	Security is a cross-cutting architectural concern
`performance-optimization`	Performance NFRs drive optimization targets
`planning`	Architecture decisions inform implementation planning
`code-review`	Review validates architectural consistency
`acceptance-testing`	NFRs become acceptance criteria

技能	关联关系
`senior-backend`	后端实现遵循架构决策
`senior-fullstack`	全栈架构遵循服务边界定义
`security-review`	安全是架构的横切关注点
`performance-optimization`	性能非功能需求驱动优化目标
`planning`	架构决策为实现规划提供输入
`code-review`	审核验证架构一致性
`acceptance-testing`	非功能需求成为验收标准

Key Principles

核心原则

Start with the simplest architecture that could work
Make decisions reversible when possible
Design for failure (everything will fail eventually)
Optimize for team cognitive load, not technical elegance
Document decisions, not just outcomes
Prefer boring technology for critical paths
Every architectural decision has a cost — make it explicit

从能满足需求的最简单架构开始
尽可能让决策可回滚
为故障做设计（所有组件最终都会故障）
优先降低团队认知负载，而非追求技术优雅
记录决策过程，而不仅仅是结果
核心路径优先选择成熟稳定的技术
每个架构决策都有成本 — 要明确列出来

Skill Type

技能类型

FLEXIBLE — Adapt architecture recommendations to the specific context. ADRs are strongly recommended for all significant decisions. Trade-off analysis is mandatory. NFRs must be quantified, not described vaguely.

灵活型 — 根据具体上下文调整架构建议。所有重要决策强烈建议编写ADR。必须做权衡分析。非功能需求必须量化，不能模糊描述。