Introduction
DDD (Domain-Driven Design) is a software design method that focuses on the business domain. In system architecture, DDD helps define service boundaries — the most difficult question when designing microservices.
1. Strategic Patterns
1.1 Ubiquitous Language
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 Bounded Context
"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 Context Map
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. Tactical Patterns
2.1 Entity vs Value Object
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 Aggregates
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
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 → Microservices Boundaries
3.1 Process
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 E-Commerce Example
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. Anti-Corruption Layer (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, ...);
}
}
Summary
| Pattern | Level | Purpose |
|---|---|---|
| Bounded Context | Strategic | Determine service boundaries |
| Context Map | Strategic | Relationship between services |
| Ubiquitous Language | Strategic | Language unification |
| Entity/Value Object | Tactical | Model domain objects |
| Aggregates | Tactical | Consistency + transaction boundary |
| Repository | Tactical | Data access abstraction |
| ACL | Integration | Protect domain from external systems |
Exercises
-
Event Storming: Hospital Management System: Patient registers → Doctor examines → Prescribes medicine → Payment → Picks up medicine. List Domain Events, Commands, and define Bounded Contexts.
-
Aggregate Design: Shopping Cart: Cart contains CartItems, each CartItem has Product reference, quantity, price. Aggregate Design. Business rules: max 20 items, quantity 1-99, total < 100M VND.
-
Context Map: Integrated E-commerce: internal (Order, Catalog, Inventory), external (Stripe Payment, GHN Shipping, SendGrid Email). Draw Context Map with relationship types.