architecture-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Architecture Design Skill

架构设计技能

Design system architecture and make strategic technical decisions.

设计系统架构并制定战略性技术决策。

Core Principle

核心原则

Good architecture enables change while maintaining simplicity.

优秀的架构能在保持简洁性的同时支持系统变更。

Architecture vs Planning

架构设计 vs 技术规划

Architecture Design (this skill):

Strategic: "How should the system be structured?"
Component interactions and boundaries
Technology and pattern choices
Long-term implications
System-level decisions

Technical Planning (technical-planning skill):

Tactical: "How do I implement feature X?"
Specific implementation tasks
Execution details
Short-term focus

Use architecture when:

Designing new systems or subsystems
Major refactors affecting multiple components
Technology selection decisions
Defining system boundaries and interfaces
Making decisions with long-term impact

Use planning when:

Implementing within existing architecture
Breaking down specific features
Task sequencing and execution

架构设计（本技能）：

战略层面："系统应如何构建？"
组件交互与边界定义
技术与模式选型
长期影响考量
系统级决策

技术规划（technical-planning技能）：

战术层面："如何实现功能X？"
具体实施任务
执行细节
短期聚焦

适用架构设计的场景：

设计新系统或子系统
影响多组件的重大重构
技术选型决策
定义系统边界与接口
制定具有长期影响的决策

适用技术规划的场景：

在现有架构内进行功能实现
拆分具体功能模块
任务排序与执行

Architecture Process

架构设计流程

1. Understand Context

1. 理解上下文

Business context:

What problem are we solving?
Who are the users?
What are the business goals?
What are the success metrics?

Technical context:

What exists today?
What constraints exist?
What must we integrate with?
What scale must we support?

Team context:

What's our expertise?
What can we maintain?
What's our velocity?

业务上下文：

我们要解决什么问题？
用户群体是谁？
业务目标是什么？
成功指标有哪些？

技术上下文：

当前已有哪些系统？
存在哪些约束条件？
必须与哪些系统集成？
需要支持多大的规模？

团队上下文：

我们具备哪些专业技能？
能够维护什么样的系统？
团队的交付速度如何？

2. Gather Requirements

2. 收集需求

Functional requirements:

What must the system do?
What are the features?
What are the user scenarios?

Non-functional requirements:

Performance: Response time, throughput
Scalability: Expected load, growth
Availability: Uptime requirements
Security: Compliance, data protection
Maintainability: Team size, skills
Cost: Budget constraints

Example:

markdown

undefined

功能性需求：

系统必须实现哪些功能？
有哪些具体特性？
用户场景有哪些？

非功能性需求：

性能：响应时间、吞吐量
可扩展性：预期负载、增长规模
可用性：上线时间要求
安全性：合规性、数据保护
可维护性：团队规模、技能水平
成本：预算约束

示例：

markdown

undefined

Requirements

需求

Functional

功能性需求

Users can search products by name/category
Users can add items to cart
Users can checkout and pay

用户可按名称/类别搜索产品
用户可将商品加入购物车
用户可完成结算与支付

Non-Functional

非功能性需求

Search response time < 200ms (p95)
Support 10,000 concurrent users
99.9% uptime
PCI DSS compliant for payments
Team of 5 developers can maintain

undefined

搜索响应时间 < 200ms (p95)
支持10,000并发用户
99.9% 上线率
支付流程符合PCI DSS合规要求
5人开发团队可维护

undefined

3. Identify Constraints

3. 识别约束条件

Technical constraints:

Must use existing authentication system
Must integrate with legacy inventory system
Database must be PostgreSQL (existing infrastructure)

Business constraints:

Must launch in 3 months
Budget of $50k for infrastructure
Must support EU data residency

Team constraints:

Team experienced in Python, less in Go
No DevOps specialist on team
Remote team across timezones

技术约束：

必须使用现有认证系统
必须与遗留库存系统集成
数据库必须为PostgreSQL (现有基础设施)

业务约束：

必须在3个月内上线
基础设施预算为5万美元
必须支持欧盟数据驻留要求

团队约束：

团队精通Python，对Go经验较少
团队无DevOps专员
跨时区远程团队

4. Consider Alternatives

4. 评估备选方案

Never design in a vacuum - consider options:

Example: Data storage choice

Option 1: PostgreSQL

Pros: Team knows it, ACID guarantees, rich query support
Cons: Vertical scaling limits, setup complexity

Option 2: MongoDB

Pros: Flexible schema, horizontal scaling
Cons: Team unfamiliar, eventual consistency

Option 3: DynamoDB

Pros: Fully managed, auto-scaling
Cons: Vendor lock-in, query limitations, cost at scale

Decision: PostgreSQL

Team expertise outweighs scaling concerns
Can re-evaluate if scale becomes issue
Faster initial development

切勿闭门造车——多考量不同选项：

示例：数据存储选型

选项1：PostgreSQL

优点：团队熟悉，ACID保证，丰富的查询支持
缺点：垂直扩展限制，部署复杂度高

选项2：MongoDB

优点：灵活的 schema，水平扩展能力
缺点：团队不熟悉，最终一致性问题

选项3：DynamoDB

优点：全托管，自动扩展
缺点：厂商锁定，查询限制，大规模场景下成本高

决策：选择PostgreSQL

团队经验的重要性超过扩展顾虑
若规模成为问题可重新评估
初始开发速度更快

5. Design System Structure

5. 设计系统结构

Define components and their responsibilities:

┌─────────────────────────────────────────────┐
│             Client Apps                      │
│  (Web, iOS, Android)                         │
└────────────────┬────────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────────┐
│          API Gateway / Load Balancer         │
└────────────────┬────────────────────────────┘
                 │
        ┌────────┴────────┐
        ▼                 ▼
┌───────────────┐  ┌───────────────┐
│   Auth        │  │   Core API     │
│   Service     │  │   Service      │
└───────┬───────┘  └───────┬───────┘
        │                  │
        │         ┌────────┴────────┐
        │         ▼                 ▼
        │  ┌──────────────┐  ┌──────────────┐
        │  │  PostgreSQL  │  │   Redis      │
        │  │  (Primary)   │  │   (Cache)    │
        │  └──────────────┘  └──────────────┘
        │
        ▼
┌───────────────┐
│   User DB     │
└───────────────┘

Component descriptions:

markdown

undefined

定义组件及其职责：

┌─────────────────────────────────────────────┐
│             Client Apps                      │
│  (Web, iOS, Android)                         │
└────────────────┬────────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────────┐
│          API Gateway / Load Balancer         │
└────────────────┬────────────────────────────┘
                 │
        ┌────────┴────────┐
        ▼                 ▼
┌───────────────┐  ┌───────────────┐
│   Auth        │  │   Core API     │
│   Service     │  │   Service      │
└───────┬───────┘  └───────┬───────┘
        │                  │
        │         ┌────────┴────────┐
        │         ▼                 ▼
        │  ┌──────────────┐  ┌──────────────┐
        │  │  PostgreSQL  │  │   Redis      │
        │  │  (Primary)   │  │   (Cache)    │
        │  └──────────────┘  └──────────────┘
        │
        ▼
┌───────────────┐
│   User DB     │
└───────────────┘

组件说明：

markdown

undefined

Components

组件

API Gateway

API网关

Responsibility: Route requests, rate limiting, authentication Technology: Nginx Dependencies: Auth Service, Core API Service Scale: 2-3 instances behind load balancer

职责： 请求路由、限流、认证 技术选型： Nginx 依赖： 认证服务、核心API服务 规模： 负载均衡后部署2-3个实例

Auth Service

认证服务

Responsibility: User authentication, session management, JWT issuing Technology: Python (Flask), PostgreSQL API: REST Scale: Stateless, 2-N instances

职责： 用户认证、会话管理、JWT签发 技术选型： Python (Flask)、PostgreSQL API类型： REST 规模： 无状态，可部署2-N个实例

Core API Service

核心API服务

Responsibility: Business logic, data access, external integrations Technology: Python (FastAPI), PostgreSQL, Redis API: REST Scale: Stateless, 2-N instances

职责： 业务逻辑、数据访问、外部集成 技术选型： Python (FastAPI)、PostgreSQL、Redis API类型： REST 规模： 无状态，可部署2-N个实例

PostgreSQL

Responsibility: Primary data store Scale: Primary with read replica

职责： 主数据存储 规模： 主库搭配只读副本

Redis

Responsibility: Session storage, caching, rate limiting Scale: Cluster mode (3 nodes)

undefined

职责： 会话存储、缓存、限流 规模： 集群模式（3节点）

undefined

6. Define Interfaces

6. 定义接口

API contracts:

markdown

undefined

API契约：

markdown

undefined

API Design

API设计

POST /api/auth/login

Purpose: Authenticate user, issue JWT

Request:

json

{
  "email": "user@example.com",
  "password": "secure_password"
}

Response (200):

json

{
  "token": "eyJ...",
  "user": {
    "id": "123",
    "email": "user@example.com",
    "name": "John Doe"
  }
}

Errors:

400: Invalid request
401: Invalid credentials
429: Rate limit exceeded

undefined

用途： 用户认证，签发JWT

请求：

json

{
  "email": "user@example.com",
  "password": "secure_password"
}

响应（200）：

json

{
  "token": "eyJ...",
  "user": {
    "id": "123",
    "email": "user@example.com",
    "name": "John Doe"
  }
}

错误：

400：无效请求
401：无效凭据
429：超出限流阈值

undefined

7. Plan for Failure

7. 故障预案规划

What can go wrong?

Database unavailable
External API down
Network partition
High load
Data corruption

Mitigation strategies:

Retry with exponential backoff
Circuit breakers for external services
Graceful degradation
Health checks and monitoring
Database backups

Example:

markdown

undefined

可能出现哪些问题？

数据库不可用
外部API故障
网络分区
高负载
数据损坏

缓解策略：

指数退避重试
外部服务熔断机制
优雅降级
健康检查与监控
数据库备份

示例：

markdown

undefined

Failure Scenarios

故障场景

Database Unavailable

数据库不可用

Impact: Cannot read/write data Mitigation:

Read replica failover (automated)
Circuit breaker after 3 failures
Cache serves stale data for 5 minutes
User sees degraded experience message Recovery: Manual failover to replica, fix primary

影响： 无法读写数据 缓解措施：

只读副本自动故障转移
3次失败后触发熔断
缓存提供5分钟过期的 stale 数据
向用户展示降级体验提示 恢复流程： 手动将副本切换为主库，修复原主库

External Payment API Down

外部支付API故障

Impact: Cannot process payments Mitigation:

Retry 3 times with exponential backoff
Queue payments for later processing
User notified of delay
Alert on-call engineer Recovery: Process queued payments once API recovers

undefined

影响： 无法处理支付 缓解措施：

指数退避重试3次
将支付任务加入队列延后处理
通知用户支付延迟
触发值班工程师告警 恢复流程： API恢复后处理队列中的支付任务

undefined

8. Document Decisions

8. 记录决策

Architecture Decision Record (ADR):

markdown

undefined

架构决策记录（ADR）：

markdown

undefined

ADR-001: Use PostgreSQL for Primary Database

ADR-001：选用PostgreSQL作为主数据库

Status: Accepted Date: 2024-01-15 Deciders: Tech Lead, Backend Team

状态： 已接受 日期： 2024-01-15 决策人： 技术负责人、后端团队

Context

背景

We need to choose a primary database for user data, products, and orders.

Requirements:

Strong consistency (ACID)
Complex queries (joins, aggregations)
< 200ms query time for 90% of queries
Support 100k users initially

我们需要为用户数据、产品数据和订单数据选择主数据库。

Requirements:

强一致性（ACID）
复杂查询（关联、聚合）
< 200ms query time for 90% of queries
初始支持10万用户

Decision

决策

Use PostgreSQL as primary database.

选用PostgreSQL作为主数据库。

Alternatives Considered

评估的备选方案

MongoDB

Pros: Flexible schema, horizontal scaling
Cons: Team unfamiliar, eventual consistency issues
Why not: Team expertise more valuable than flexibility

Pros: Flexible schema, horizontal scaling
Cons: Team unfamiliar, eventual consistency issues
Why not: Team expertise more valuable than flexibility

DynamoDB

Pros: Managed service, auto-scaling
Cons: Vendor lock-in, limited query capability, cost
Why not: Query limitations would hurt development velocity

Pros: Managed service, auto-scaling
Cons: Vendor lock-in, limited query capability, cost
Why not: Query limitations would hurt development velocity

MySQL

Pros: Similar to PostgreSQL, team knows it
Cons: Less feature-rich than PostgreSQL
Why not: PostgreSQL offers JSON support, better full-text search

Pros: Similar to PostgreSQL, team knows it
Cons: Less feature-rich than PostgreSQL
Why not: PostgreSQL offers JSON support, better full-text search

Consequences

后果

Positive:

Team can be productive immediately
Strong consistency guarantees
Rich query capabilities
JSON support for flexible data

Negative:

Vertical scaling limits (mitigated: can add read replicas)
More complex than managed services (mitigated: use RDS)
Higher operational overhead

Trade-offs:

Chose familiarity over horizontal scaling
Chose rich queries over eventual consistency
Can re-evaluate if scale requirements change

Positive:

Team can be productive immediately
Strong consistency guarantees
Rich query capabilities
JSON support for flexible data

Negative:

Vertical scaling limits (mitigated: can add read replicas)
More complex than managed services (mitigated: use RDS)
Higher operational overhead

Trade-offs:

Chose familiarity over horizontal scaling
Chose rich queries over eventual consistency
Can re-evaluate if scale requirements change

Validation

验证

Team confirmed expertise in PostgreSQL
Load testing shows meets performance requirements
Cost analysis shows acceptable for first year

undefined

Team confirmed expertise in PostgreSQL
Load testing shows meets performance requirements
Cost analysis shows acceptable for first year

undefined

Architecture Principles

架构设计原则

1. Simplicity

1. 简洁性

Start simple, add complexity only when needed.

❌ BAD: Microservices from day 1 with 20 services
✅ GOOD: Start with monolith, split when needed

Apply YAGNI: You Aren't Gonna Need It

Don't build for hypothetical future
Add when actually needed
Simpler is easier to maintain

从简开始，仅在必要时增加复杂度。

❌ 错误：第一天就搭建20个服务的微服务架构
✅ 正确：从单体应用开始，必要时再拆分

应用YAGNI原则：你不会需要它

不为假设的未来需求做开发
仅在实际需要时添加功能
简洁的系统更易于维护

2. Separation of Concerns

2. 关注点分离

Each component has one clear responsibility.

✅ GOOD:
- Auth Service: Authentication only
- User Service: User profile management
- Order Service: Order processing

❌ BAD:
- God Service: Does everything

Apply SOLID principles:

Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

每个组件仅有一个明确的职责。

✅ 正确：
- 认证服务：仅负责认证
- 用户服务：用户资料管理
- 订单服务：订单处理

❌ 错误：
- 上帝服务：包揽所有功能

应用SOLID原则：

单一职责原则
开闭原则
里氏替换原则
接口隔离原则
依赖倒置原则

3. Loose Coupling

3. 松耦合

Components depend on interfaces, not implementations.

typescript

// ❌ BAD: Tight coupling
class OrderService {
  constructor(private db: PostgresDatabase) {}
}

// ✅ GOOD: Loose coupling
class OrderService {
  constructor(private db: Database) {}  // Interface
}

Benefits:

Easier to test (mock interface)
Easier to swap implementations
Components can evolve independently

组件依赖于接口而非具体实现。

typescript

// ❌ 错误：紧耦合
class OrderService {
  constructor(private db: PostgresDatabase) {}
}

// ✅ 正确：松耦合
class OrderService {
  constructor(private db: Database) {}  // 接口
}

优势：

更易于测试（可模拟接口）
更易于替换实现
组件可独立演进

4. High Cohesion

4. 高内聚

Related functionality stays together.

✅ GOOD:
user/
  - create_user.ts
  - update_user.ts
  - delete_user.ts
  - user_repository.ts

❌ BAD:
create/
  - create_user.ts
  - create_order.ts
update/
  - update_user.ts
  - update_order.ts

相关功能应集中在一起。

✅ 正确：
user/
  - create_user.ts
  - update_user.ts
  - delete_user.ts
  - user_repository.ts

❌ 错误：
create/
  - create_user.ts
  - create_order.ts
update/
  - update_user.ts
  - update_order.ts

5. Explicit Over Implicit

5. 显式化优于隐式化

Make dependencies and contracts clear.

typescript

// ❌ BAD: Implicit dependency
function processOrder(orderId: string) {
  const db = global.database  // Where does this come from?
  // ...
}

// ✅ GOOD: Explicit dependency
function processOrder(
  orderId: string,
  db: Database,
  logger: Logger
) {
  // Dependencies are clear
}

明确依赖关系与契约。

typescript

// ❌ 错误：隐式依赖
function processOrder(orderId: string) {
  const db = global.database  // 来源不明
  // ...
}

// ✅ 正确：显式依赖
function processOrder(
  orderId: string,
  db: Database,
  logger: Logger
) {
  // 依赖关系明确
}

6. Fail Fast

6. 快速失败

Detect and report errors early.

typescript

// ❌ BAD: Silent failure
function divide(a: number, b: number) {
  if (b === 0) return 0  // Wrong!
  return a / b
}

// ✅ GOOD: Fail fast
function divide(a: number, b: number) {
  if (b === 0) {
    throw new Error('Division by zero')
  }
  return a / b
}

尽早检测并报告错误。

typescript

// ❌ 错误：静默失败
function divide(a: number, b: number) {
  if (b === 0) return 0  // 错误处理方式！
  return a / b
}

// ✅ 正确：快速失败
function divide(a: number, b: number) {
  if (b === 0) {
    throw new Error('Division by zero')
  }
  return a / b
}

7. Design for Testability

7. 可测试性设计

Make it easy to test.

typescript

// ❌ BAD: Hard to test
class OrderService {
  processOrder(orderId: string) {
    const db = new PostgresDatabase()  // Can't mock
    const api = new PaymentAPI()       // Can't mock
    // ...
  }
}

// ✅ GOOD: Easy to test
class OrderService {
  constructor(
    private db: Database,      // Can inject mock
    private api: PaymentAPI    // Can inject mock
  ) {}

  processOrder(orderId: string) {
    // ...
  }
}

让系统易于测试。

typescript

// ❌ 错误：难以测试
class OrderService {
  processOrder(orderId: string) {
    const db = new PostgresDatabase()  // 无法模拟
    const api = new PaymentAPI()       // 无法模拟
    // ...
  }
}

// ✅ 正确：易于测试
class OrderService {
  constructor(
    private db: Database,      // 可注入模拟实现
    private api: PaymentAPI    // 可注入模拟实现
  ) {}

  processOrder(orderId: string) {
    // ...
  }
}

Common Architecture Patterns

常见架构模式

Layered Architecture

分层架构

┌─────────────────────┐
│  Presentation       │ (UI, API controllers)
├─────────────────────┤
│  Business Logic     │ (Domain, services)
├─────────────────────┤
│  Data Access        │ (Repositories, ORMs)
├─────────────────────┤
│  Database           │ (Storage)
└─────────────────────┘

When to use: Simple to moderate complexity

┌─────────────────────┐
│  表现层             │ (UI、API控制器)
├─────────────────────┤
│  业务逻辑层         │ (领域模型、服务)
├─────────────────────┤
│  数据访问层         │ (仓储、ORM)
├─────────────────────┤
│  数据库层           │ (存储)
└─────────────────────┘

适用场景： 简单到中等复杂度的系统

Hexagonal Architecture (Ports & Adapters)

六边形架构（Ports & Adapters）

        ┌───────────────────────┐
        │   External Systems    │
        │  (UI, DB, APIs)       │
        └──────────┬────────────┘
                   │
        ┌──────────▼────────────┐
        │      Adapters         │ (Implementation)
        │  (REST, PostgreSQL)   │
        └──────────┬────────────┘
                   │
        ┌──────────▼────────────┐
        │       Ports           │ (Interfaces)
        │  (IUserRepo, IAuth)   │
        └──────────┬────────────┘
                   │
        ┌──────────▼────────────┐
        │    Core Domain        │ (Business logic)
        │    (Pure logic)       │
        └───────────────────────┘

When to use: Want to isolate business logic, multiple frontends

        ┌───────────────────────┐
        │   外部系统            │
        │  (UI、DB、APIs)       │
        └──────────┬────────────┘
                   │
        ┌──────────▼────────────┐
        │      适配器            │ (具体实现)
        │  (REST、PostgreSQL)   │
        └──────────┬────────────┘
                   │
        ┌──────────▼────────────┐
        │       端口             │ (接口)
        │  (IUserRepo、IAuth)   │
        └──────────┬────────────┘
                   │
        ┌──────────▼────────────┐
        │    核心领域逻辑        │ (业务逻辑)
        │    (纯逻辑实现)       │
        └───────────────────────┘

适用场景： 希望隔离业务逻辑、多前端系统

Microservices

微服务架构

┌─────────┐  ┌─────────┐  ┌─────────┐
│  User   │  │  Order  │  │ Payment │
│ Service │  │ Service │  │ Service │
└────┬────┘  └────┬────┘  └────┬────┘
     │            │            │
     └────────────┴────────────┘
                  │
          ┌───────▼────────┐
          │  Message Bus   │
          │  (Event-driven)│
          └────────────────┘

When to use: Large team, need independent deploy, clear boundaries

Avoid when: Small team, unclear boundaries, early stage

┌─────────┐  ┌─────────┐  ┌─────────┐
│  用户服务│  │  订单服务│  │ 支付服务│
│ Service │  │ Service │  │ Service │
└────┬────┘  └────┬────┘  └────┬────┘
     │            │            │
     └────────────┴────────────┘
                  │
          ┌───────▼────────┐
          │  消息总线       │
          │  (事件驱动)     │
          └────────────────┘

适用场景： 大型团队、需要独立部署、边界清晰的系统

避免场景： 小型团队、边界不清晰、项目初期

Event-Driven Architecture

事件驱动架构

┌─────────┐       ┌─────────────┐       ┌─────────┐
│Producer │──────▶│ Event Bus   │──────▶│Consumer │
└─────────┘       └─────────────┘       └─────────┘

When to use: Async processing, decoupled systems, audit trails

┌─────────┐       ┌─────────────┐       ┌─────────┐
│生产者   │──────▶│ 事件总线     │──────▶│消费者   │
└─────────┘       └─────────────┘       └─────────┘

适用场景： 异步处理、解耦系统、审计追踪

Anti-Patterns

反模式

❌ Premature Optimization

❌ 过早优化

Don't optimize for scale you don't have.

BAD: Build microservices for 100 users
GOOD: Start with monolith, split when needed

不要为当前不具备的规模做优化。

错误：为100个用户搭建微服务
正确：从单体应用开始，必要时再拆分

❌ Resume-Driven Architecture

❌ 简历驱动架构

Don't choose technology to pad resume.

BAD: "I want to learn Kubernetes, let's use it"
GOOD: "Kubernetes fits our scale needs"

不要为了丰富简历而选择技术。

错误："我想学习Kubernetes，所以我们用它"
正确："Kubernetes符合我们的规模需求"

❌ Distributed Monolith

❌ 分布式单体

Microservices that are tightly coupled.

BAD: Service A can't deploy without Service B
GOOD: Services are independently deployable

紧耦合的微服务。

错误：服务A部署必须依赖服务B
正确：服务可独立部署

❌ Big Ball of Mud

❌ 大泥球

No structure, everything depends on everything.

BAD: Any code can call any other code
GOOD: Clear layers and boundaries

无结构，所有代码相互依赖。

错误：任何代码都能调用其他代码
正确：清晰的分层与边界

❌ Analysis Paralysis

❌ 分析瘫痪

Over-analyzing, never shipping.

BAD: Spend 6 months on perfect architecture
GOOD: Design enough to start, iterate

过度分析，永远不交付。

错误：花6个月设计完美架构
正确：设计到可启动的程度，再迭代优化

Architecture Review Checklist

架构评审 Checklist

Integration with Other Skills

与其他技能的集成

Apply solid-principles - Guide component design
Apply simplicity-principles - KISS, YAGNI
Apply orthogonality-principle - Independent components
Apply structural-design-principles - Composition patterns
Use technical-planning - For implementation after design

应用solid-principles - 指导组件设计
应用simplicity-principles - KISS, YAGNI
应用orthogonality-principle - 独立组件
应用structural-design-principles - 组合模式
使用technical-planning - 设计完成后用于实施

Remember

谨记

Simplicity first - Start simple, add complexity when needed
Document decisions - Future you will thank you
Consider alternatives - Never the first idea only
State trade-offs - Every decision has consequences
Design for change - Systems evolve

The best architecture is the one that's simple enough to ship and flexible enough to evolve.

简洁优先 - 从简开始，必要时增加复杂度
记录决策 - 未来的你会感谢现在的自己
考量备选方案 - 不要只看第一个想法
说明权衡 - 每个决策都有代价
为变更设计 - 系统会演进

最好的架构是足够简洁可交付，同时足够灵活可演进的架构。