Bạn định nghĩa ranh giới service bằng bounded context của DDD như thế nào?

Question

Accepted Answer

Ranh giới service tốt đi theo **năng lực nghiệp vụ**, không phải các tầng kỹ thuật. **Domain-Driven Design (DDD)** cho một công cụ chính xác cho việc này: **bounded context** — một ranh giới trong đó một mô hình miền và các thuật ngữ của nó nhất quán.

## Bounded context

Từ "Customer" có thể mang nghĩa khác nhau trong các ngữ cảnh khác nhau. Mỗi bounded context sở hữu mô hình riêng của mình, và một microservice thường ánh xạ tới một context.

```text
┌───────────────────┐   ┌────────────────────┐
│  Sales context    │   │  Support context   │
│  Customer =       │   │  Customer =        │
│   leads, orders   │   │   tickets, SLAs    │
└───────────────────┘   └────────────────────┘
   một service             một service khác
```

## Cách tìm ranh giới

- **Căn theo năng lực nghiệp vụ** (Orders, Billing, Shipping), không phải danh từ hay bảng DB.
- **Cohesion cao bên trong, coupling lỏng xuyên qua** ranh giới.
- Quan sát nơi **ngôn ngữ chung (ubiquitous language)** thay đổi — đó thường là một mép của context.
- Dùng một **context map** để ghi lại các mối quan hệ (upstream/downstream).

## Anti-pattern

```text
✗ Entity service ("User service", "Product service") — quá mịn, hay tán gẫu
✗ Tách theo tầng kỹ thuật (một "database service")
✗ Ranh giới buộc phải có một distributed transaction cho mọi thao tác
```

Nếu hai service liên tục gọi nhau để hoàn thành một thao tác, ranh giới có lẽ đã sai.

## Tại sao điều này quan trọng

Ranh giới quyết định sớm rất tốn kém để dời về sau, vì chúng cứng lại thành các API và database mà các team khác phụ thuộc vào.

Bounded context của DDD cho bạn một cách có nguyên tắc để vạch những đường ranh đó dọc theo nghiệp vụ, nhờ đó các service giữ được sự gắn kết và có thể tiến hóa độc lập thay vì liên tục phải phối hợp.