┌─────────────────────────────────────────────────────────┐
│                    Frameworks & Drivers                  │
│  (Web, DB, External APIs, UI)                           │
│                                                          │
│  ┌───────────────────────────────────────────────────┐ │
│  │              Interface Adapters                    │ │
│  │  (Controllers, Presenters, Gateways)              │ │
│  │                                                    │ │
│  │  ┌─────────────────────────────────────────────┐ │ │
│  │  │        Application Business Rules           │ │ │
│  │  │  (Use Cases, Services)                      │ │ │
│  │  │                                              │ │ │
│  │  │  ┌───────────────────────────────────────┐ │ │ │
│  │  │  │   Enterprise Business Rules           │ │ │ │
│  │  │  │  (Entities, Domain Services)          │ │ │ │
│  │  │  └────────────────────────────────────────┘ │ │ │
│  │  └─────────────────────────────────────────────┘ │ │
│  └───────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘

Infrastructure → Adapter → Application → Domain
        ✓           ✓           ✓
Domain ↛ Application ↛ Adapter ↛ Infrastructure
    ✗           ✗           ✗

What problem are you solving?
├── 需要建立物件（Need to create objects?）
│   └── 需要幾個實例？（How many instances?）
│       ├── 只需一個 ──→ ✅ Singleton
│       └── 多個 ──→ 建構是否複雜？（Complex construction?）
│           ├── 是，參數很多 ──→ ✅ Builder
│           └── 否 ──→ 誰決定具體類別？（Who decides concrete class?）
│               ├── 子類別決定 ──→ ✅ Factory Method
│               ├── 需要產品族 ──→ ✅ Abstract Factory
│               └── 複製既有物件 ──→ ✅ Prototype
│
├── 需要組織物件/類別結構（Need to structure objects/classes?）
│   └── 目標是什麼？（What's the goal?）
│       ├── 匹配不相容介面 ──→ ✅ Adapter
│       ├── 簡化複雜子系統 ──→ ✅ Facade
│       ├── 動態添加職責 ──→ ✅ Decorator
│       ├── 控制物件存取 ──→ ✅ Proxy
│       ├── 樹狀/階層結構 ──→ ✅ Composite
│       ├── 共享以最小化記憶體 ──→ ✅ Flyweight
│       └── 分離抽象與實作 ──→ ✅ Bridge
│
└── 需要管理物件間的行為/通訊（Need to manage behavior/communication?）
    └── 目標是什麼？
        ├── 請求沿鏈傳遞 ──→ ✅ Chain of Responsibility
        ├── 封裝請求/支援撤銷 ──→ ✅ Command
        ├── 定義演算法骨架 ──→ ✅ Template Method
        ├── 可互換的演算法策略 ──→ ✅ Strategy
        ├── 遍歷集合元素 ──→ ✅ Iterator
        ├── 物件間一對多通知 ──→ ✅ Observer
        ├── 物件狀態驅動行為改變 ──→ ✅ State
        ├── 集中管理物件間互動 ──→ ✅ Mediator
        ├── 保存與還原物件狀態 ──→ ✅ Memento
        ├── 對結構新增操作而不修改類別 ──→ ✅ Visitor
        └── 定義語法的解釋器 ──→ ✅ Interpreter

com.company.project/
├── domain/                      # 企業業務規則層
│   ├── model/                   # Entities, Value Objects
│   ├── service/                 # Domain Services
│   └── repository/              # Repository Interfaces
│
├── application/                 # 應用業務規則層
│   ├── service/                 # Use Cases
│   ├── dto/                     # Command, Query, Response
│   └── exception/               # Business Exceptions
│
├── adapter/                     # 介面配接器層
│   ├── in/                      # Inbound (web, messaging)
│   └── out/                     # Outbound (persistence, external)
│
└── infrastructure/              # 基礎建設層
    ├── config/                  # Configuration
    ├── security/                # Security
    └── common/                  # Utilities

## 訂單管理系統

### 核心概念
- Entity: Order, OrderItem, Customer
- Value Object: Money, Address, OrderStatus
- Aggregate: Order (root) + OrderItems
- Domain Service: PricingService, DiscountService

### Use Cases
1. 建立訂單  2. 更新訂單  3. 確認訂單  4. 取消訂單  5. 查詢訂單

### 對外介面
- REST API → 資料庫 → 付款服務

com.company.project/
├── order/              # 訂單模組
│   ├── domain/
│   ├── application/
│   └── adapter/
├── customer/           # 客戶模組
├── product/            # 產品模組
└── shared/             # 共用模組

order → customer (允許)
customer → order (禁止 - 循環依賴)

解決方案：使用事件或共用模組
order → shared ← customer

✅ 正確
GET    /api/orders           # 查詢列表
GET    /api/orders/{id}      # 查詢單一
POST   /api/orders           # 建立
PUT    /api/orders/{id}      # 更新
DELETE /api/orders/{id}      # 刪除

❌ 錯誤
GET    /api/getOrders        # 不使用動詞
POST   /api/createOrder      # 不使用動詞

PUT    /api/orders/{id}/confirm    # 確認訂單
PUT    /api/orders/{id}/cancel     # 取消訂單

{ "success": true, "data": { ... } }

{ "success": false, "code": "error.order.not_found", "message": "找不到訂單" }

Client → HTTP Cache → Application Cache (Redis) → Database

# ADR-001: 採用 Clean Architecture

## 狀態：已接受

## 背景
專案需要高可維護性與可測試性

## 決策
採用 Clean Architecture，分為 Domain、Application、Adapter、Infrastructure 四層

## 理由
1. 可測試性：Domain 層獨立，易於單元測試
2. 可維護性：清楚的層級劃分
3. 技術獨立：未來可更換技術

## 後果
- 優點：程式碼品質提升
- 缺點：初期開發較慢