Back to Details

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

执行动作

  1. Identify functional requirements (capabilities)
  2. Define non-functional requirements (quality attributes)
  3. Identify constraints (budget, team, timeline, compliance)
  4. Map integration points with existing systems
  5. Establish success criteria and SLOs
  1. 识别功能需求（系统能力）
  2. 定义非功能需求（质量属性）
  3. 明确约束条件（预算、团队、时间线、合规要求）
  4. 梳理与现有系统的集成点
  5. 制定成功标准和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

执行动作

  1. Evaluate architectural styles (monolith, microservices, event-driven)
  2. Design component boundaries and interfaces
  3. Define data architecture (storage, flow, consistency)
  4. Plan infrastructure and deployment topology
  5. Address cross-cutting concerns (auth, logging, monitoring)
  1. 评估架构风格（单体、微服务、事件驱动）
  2. 设计组件边界和接口
  3. 定义数据架构（存储、流转、一致性）
  4. 规划基础设施和部署拓扑
  5. 处理横切关注点（认证、日志、监控）

Architecture Style Decision Table

架构风格决策表

FactorMonolithModular MonolithMicroservicesServerless
Team size < 10PreferredStrong fitOverkillGood for bursty
Team size > 30ChallengingGoodPreferredDepends
Domain well-understoodGood fitGood fitNot needed yetGood fit
Domain evolving rapidlyFine to startGood fitToo earlyGood fit
Need independent deploymentNot possibleLimitedKey benefitBuilt-in
Operational maturity lowGood fitGood fitHigh riskManaged risk
Variable/bursty loadOver-provisionedOver-provisionedPossibleStrong 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

权衡分析：常见配对

ImprovingMay Degrade
ConsistencyAvailability, Latency
PerformanceMaintainability, Cost
SecurityUsability, Performance
ScalabilitySimplicity, Cost
FlexibilityPerformance, Complexity
Time to MarketQuality, 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

执行动作

  1. Write Architecture Decision Records for key decisions
  2. Create system context and container diagrams (C4 model)
  3. Validate against non-functional requirements
  4. Identify risks and mitigation strategies
  5. Define evolutionary architecture guardrails
  1. 为核心决策编写架构决策记录（ADR）
  2. 绘制系统上下文和容器图（C4模型）
  3. 对照非功能需求验证设计
  4. 识别风险和缓解策略
  5. 定义演进式架构护栏

ADR Format

ADR格式

markdown
undefined
markdown
undefined

ADR-{number}: {Title}

ADR-{number}: {Title}

Status

Status

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

Context

Context

What is the issue motivating this decision?
What is the issue motivating this decision?

Decision

Decision

What change are we proposing?
What change are we proposing?

Consequences

Consequences

Positive

Positive

  • [Benefit 1]
  • [Benefit 2]
  • [Benefit 1]
  • [Benefit 2]

Negative

Negative

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

Risks

Risks

  • [Risk and mitigation]
  • [Risk and mitigation]

Alternatives Considered

Alternatives Considered

OptionProsConsVerdict
Option A......Chosen
Option B......Rejected because...
undefined
OptionProsConsVerdict
Option A......Chosen
Option B......Rejected because...
undefined

C4 Model Levels

C4模型层级

LevelShowsWhen to Use
Level 1: System ContextUsers and external systemsAlways
Level 2: ContainerMajor technical building blocksAlways
Level 3: ComponentComponents within containersComplex services
Level 4: CodeClass-level detailCritical/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

水平扩缩容决策表

PatternUse WhenImplementation
Load BalancingMultiple instances of same serviceRound-robin, least connections, IP hash
Stateless ServicesNeed to add/remove instances freelyJWT/external session store
Auto-scalingVariable load patternsCPU/memory/request-rate triggers
Read ReplicasRead-heavy workloadsRoute reads to replicas, writes to primary
模式使用场景实现方式
负载均衡同一服务运行多个实例轮询、最少连接、IP哈希
无状态服务需要自由增减实例JWT/外置会话存储
自动扩缩容负载模式可变CPU/内存/请求速率触发
只读副本读密集型工作负载读请求路由到副本，写请求走主库

Sharding Strategy Decision Table

分库分表策略决策表

StrategyHowGood For
Hash-basedConsistent hash of keyEven distribution
Range-basedDate range, ID rangeTime-series data
GeographicBy region/countryData locality
Tenant-basedPer customerMulti-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

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

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

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

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

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框架

TermDefinitionExample
SLIMeasurable metricRequest latency, error rate
SLOTarget value99.9% availability
SLAContractual commitment99.5% with penalty clause
Error Budget1 - SLO0.1% = 8.76h/year
术语定义示例
SLI可衡量指标请求延迟、错误率
SLO目标值99.9%可用性
SLA合同承诺99.5%可用性附带惩罚条款
错误预算1 - SLO0.1% = 每年8.76小时容错时间

Anti-Patterns / Common Mistakes

反模式/常见错误

Anti-PatternWhy It Is WrongCorrect Approach
Resume-driven architectureComplexity without benefitChoose simplest solution that works
Distributed monolithAll downsides of bothEither true monolith or true microservices
Premature optimizationScaling for 1M users with 100Design for current + 10x, not 1000x
Golden hammerOne technology for everythingRight tool for each problem
Architecture without validationUntested assumptionsLoad test, failure test, validate
Big upfront design without iterationRequirements changeEvolutionary architecture with guardrails
Vague NFRs ("fast", "scalable")Cannot be validatedQuantified targets with measurement
反模式问题点正确做法
简历驱动架构无意义的复杂度提升选择能满足需求的最简单方案
分布式单体同时具备两种架构的所有缺点要么做真正的单体，要么做真正的微服务
过早优化只有100个用户就为100万用户做扩容设计支撑当前+10倍规模即可，不需要考虑1000倍
golden hammer所有问题都用同一个技术解决为每个问题选择最合适的工具
未经验证的架构全是未测试的假设做压测、故障测试、验证设计
一次性的大规模前置设计无迭代需求会发生变化带护栏的演进式架构
模糊的非功能需求（"快"、"可扩展"）无法验证带衡量方式的量化目标

Subagent Dispatch Opportunities

子Agent调度场景

Task PatternDispatch ToWhen
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

集成点

SkillRelationship
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。必须做权衡分析。非功能需求必须量化，不能模糊描述。