簡介
DDD（領域驅動設計）是一種專注於業務領域的軟體設計方法。在系統架構中，DDD 幫助定義服務邊界－設計微服務時最困難的問題。
1. 戰略模式
1.1 無所不在的語言
Vấn đề: Developers và Business nói khác ngôn ngữ
Business: "Khi khách hàng đặt hàng..."
Developer: "Khi user tạo order record..."
Business: "Sản phẩm hết hàng"
Developer: "Product inventory count = 0"
Ubiquitous Language:
Thống nhất ngôn ngữ giữa dev và business
Dùng CÙNG thuật ngữ trong code, docs, meetings
// Tốt - dùng domain language
class Order {
placeOrder()
cancelOrder()
shipOrder()
}
// Xấu - dùng technical language
class OrderDAO {
insertRecord()
deleteRecord()
updateStatus()
}
1.2 有界上下文
"Product" nghĩa khác nhau tùy context:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Catalog Context │ │ Inventory Context│ │ Pricing Context │
│ │ │ │ │ │
│ Product: │ │ Product: │ │ Product: │
│ - name │ │ - SKU │ │ - base_price │
│ - description │ │ - quantity │ │ - discount │
│ - images │ │ - warehouse │ │ - margin │
│ - categories │ │ - reorder_level │ │ - tax_rate │
│ - reviews │ │ - supplier │ │ - currency │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Mỗi Bounded Context:
- Có MODEL riêng cho cùng concept
- Có NGÔN NGỮ riêng
- Có DATABASE riêng
→ Tương ứng 1 Microservice!
1.3 上下文映射
Các Bounded Contexts quan hệ thế nào?
┌───────────┐ ┌───────────┐
│ Catalog │◄─ ACL ─►│ Inventory │
│ Context │ │ Context │
└─────┬─────┘ └───────────┘
│
Conformist
│
┌─────▼─────┐ ┌───────────┐
│ Order │──OHS/PL─►│ Payment │
│ Context │ │ Context │
└─────┬─────┘ └───────────┘
│
Partnership
│
┌─────▼─────┐
│ Shipping │
│ Context │
└───────────┘
Relationships:
- Partnership: Hai teams hợp tác chặt
- Customer-Supplier: Downstream phụ thuộc Upstream
- Conformist: Downstream chấp nhận model của Upstream
- ACL (Anti-Corruption Layer): Translate giữa models
- OHS (Open Host Service): Upstream cung cấp API chuẩn
- PL (Published Language): Schema chung (JSON, Protobuf)
2. 戰術模式
2.1 實體與值對象
Entity: Có identity, thay đổi theo thời gian
class Order {
id: UUID // Identity
status: string // Thay đổi
items: OrderItem[]
}
// 2 Orders khác nhau vì ID khác nhau
Value Object: Không có identity, immutable
class Money {
amount: number
currency: string
}
// Money(100, "VND") == Money(100, "VND")
// So sánh bằng VALUE, không phải reference
class Address {
street: string
city: string
country: string
}
2.2 聚合
Aggregate = cluster of entities + value objects
Có 1 Aggregate Root (entry point)
Bên ngoài chỉ access qua Aggregate Root
┌──────────────────────────────────┐
│ Order Aggregate │
│ │
│ ┌───────────────────┐ │
│ │ Order (Root) │ │
│ │ - id │ │
│ │ - status │ │
│ │ - placedAt │ │
│ │ │ │
│ │ ┌─────────────┐ │ │
│ │ │ OrderItem │ │ Bên ngoài│
│ │ │ - productId │ │ KHÔNG │
│ │ │ - quantity │ │ access │
│ │ │ - price │ │ trực tiếp│
│ │ └─────────────┘ │ OrderItem│
│ │ │ │
│ │ ┌─────────────┐ │ │
│ │ │ Money │ │ │
│ │ │ (total) │ │ │
│ │ └─────────────┘ │ │
│ └───────────────────┘ │
└──────────────────────────────────┘
Rules:
1. Aggregate Root enforce business rules
2. Transactions = 1 Aggregate
3. Reference other Aggregates bằng ID (không object reference)
4. Consistency boundary = Aggregate boundary
2.3 儲存庫
Repository = interface để persist/retrieve Aggregates
interface OrderRepository {
findById(id: OrderId): Order | null
save(order: Order): void
findByUserId(userId: UserId): Order[]
}
// Implementation ẩn bên trong
class PostgresOrderRepository implements OrderRepository {
async findById(id: OrderId): Promise<Order | null> {
const row = await db.query('SELECT * FROM orders WHERE id = $1', [id]);
return row ? this.toDomain(row) : null;
}
}
Rule: 1 Repository per Aggregate Root
✅ OrderRepository
❌ OrderItemRepository (access qua Order)
3. DDD → 微服務邊界
3.1 流程
Step 1: Event Storming
Post-it notes trên tường
Orange: Domain Events (OrderPlaced, PaymentReceived)
Blue: Commands (PlaceOrder, ChargePayment)
Yellow: Aggregates (Order, Payment)
Pink: Policies / Business Rules
Step 2: Identify Bounded Contexts
Nhóm events/commands/aggregates liên quan
→ Mỗi nhóm = 1 Bounded Context
Step 3: Define Context Relationships
Context Map: Partnership, ACL, etc.
Step 4: Map to Services
1 Bounded Context ≈ 1 Microservice
(có thể split thêm nếu context quá lớn)
3.2 電子商務範例
Event Storming Results:
ProductAdded → ProductPriceChanged → ProductSearched
→ Catalog Context (Service)
InventoryReceived → StockReserved → StockReleased
→ Inventory Context (Service)
OrderPlaced → OrderConfirmed → OrderShipped → OrderDelivered
→ Order Context (Service)
PaymentRequested → PaymentCharged → PaymentRefunded
→ Payment Context (Service)
ShipmentCreated → ShipmentTracked → ShipmentDelivered
→ Shipping Context (Service)
Context Map:
Order ──uses──► Catalog (to get product info)
Order ──uses──► Inventory (to reserve stock)
Order ──uses──► Payment (to charge)
Order ──uses──► Shipping (to ship)
4. 反腐敗層（ACL）
Vấn đề: External service (payment gateway) có model khác
External Payment API:
{ "transaction_id": "xxx", "amt": 100, "ccy": "USD" }
Our Domain:
{ "paymentId": "xxx", "amount": Money(100, "USD") }
ACL translates:
┌──────────────┐ ┌───────────┐ ┌──────────────┐
│ Our Domain │────►│ ACL │────►│ External API │
│ Payment │ │ Translate │ │ Stripe/VNPay │
│ Model │◄────│ Adapter │◄────│ Raw response │
└──────────────┘ └───────────┘ └──────────────┘
// ACL Implementation
class PaymentGatewayACL {
async charge(payment: DomainPayment): DomainResult {
// Translate to external model
const externalReq = {
amt: payment.amount.value,
ccy: payment.amount.currency,
};
// Call external API
const response = await stripe.charge(externalReq);
// Translate back to domain model
return new DomainResult(response.transaction_id, ...);
}
}
總結
| 圖案 | 水平 | 目的 |
|---|---|---|
| 有界脈絡 | 戰略 | 確定服務邊界 |
| 上下文地圖 | 策略 | 服務之間的關係 |
| 無所不在的語言 | 戰略 | 語言統一 |
| 實體/值物件 | 戰術 | 模型域物件 |
| 骨材 | 戰術 | 一致性+事務邊界 |
| 存儲庫 | 戰術 | 資料存取抽象 |
| 存取控制 | 整合 | 保護域免受外部系統的影響 |
練習
-
事件風暴： 醫院管理系統：病人掛號→醫師檢查→開藥→付款→取藥。列出領域事件、指令並定義有界上下文。
-
聚合設計： 購物車：購物車包含購物車項目，每個購物車項目都有產品參考、數量、價格。整體設計。業務規則：最多 20 件商品，數量 1-99，總計 < 1 億越南盾。
-
上下文圖： 整合電子商務：內部（訂單、目錄、庫存）、外部（Stripe Payment、GHN Shipping、SendGrid Email）。繪製具有關係類型的上下文圖。