はじめに
サービスの分離は、マイクロサービスに移行する際のアーキテクチャ上の最も重要な決定事項です。分割が小さすぎる → 複雑さが爆発します。分割が大きすぎる→分散モノリス。この記事では、サービス境界を適切に定義する体系的な方法について説明します。
1. 分離の原則
1.1 サービスに対する単一の責任
各サービスは 独自のビジネス機能を担当します。
- ユーザーサービス → ユーザーライフサイクル管理（登録、ログイン、プロフィール）
- 製品サービス → 製品カタログ、検索、レビュー
- 注文サービス → 注文処理、履行、履歴
1.2 2 つの主な戦略
ビジネス能力ごとに分解:
組織が提供するビジネス機能に基づいて、次のことを行います。
E-Commerce Business Capabilities:
├── Customer Management → User Service
├── Product Management → Product Service
├── Order Management → Order Service
├── Payment Processing → Payment Service
├── Inventory Management → Inventory Service
└── Shipping & Delivery → Shipping Service
サブドメインごとに分解 (DDD):
DDD 経由で識別されたサブドメインに基づいて:
Core Subdomains (competitive advantage):
├── Product Catalog → Product Service (custom-built, best team)
├── Order Processing → Order Service (complex logic)
Supporting Subdomains (necessary but not differentiating):
├── Inventory → Inventory Service
├── Customer Profile → User Service
Generic Subdomains (solved problems):
├── Authentication → Keycloak (off-the-shelf)
├── Payment Gateway → Stripe integration
├── Email → SendGrid/SES
1.3 正しいサービス境界標識
- サービスは 独立して開発、展開、拡張可能
- サービス A の変更でサービス B の変更が必要になることはほとんどありません
- 各サービスには独自の データベースがあります (共有テーブルはありません)
- チームは他のチームと 調整する必要なく サービスに取り組むことができます
- サービスには 凝集した API があり、密接に関連したエンドポイント
2. コンテキスト マッピング パターン
境界コンテキストを特定したら、それらの間の関係を定義する必要があります。
2.1 パートナーシップ
2 つのチームは緊密に協力し、インターフェースを共同開発します。
Product Team ←→ Search Team
(cùng định nghĩa product schema cho search indexing)
2.2 顧客とサプライヤー
上流 (サプライヤー) はデータ/API を提供し、下流 (顧客) は以下を消費します。
Product Service (Supplier) → Order Service (Customer)
(Order Service cần product info nhưng không thay đổi product)
2.3 破損防止層 (ACL)
ドメイン モデルを外部/レガシー システムから保護するための変換レイヤー:
┌──────────┐ ┌─────┐ ┌──────────────┐
│ Order │ ──► │ ACL │ ──► │ Legacy ERP │
│ Service │ │ │ │ (SOAP/XML) │
└──────────┘ └─────┘ └──────────────┘
ACL convert REST/JSON ↔ SOAP/XML
3. アンチパターンは避けるべきです
3.1 分散モノリス
❌ Services phụ thuộc chặt chẽ:
Service A → Service B → Service C → Service A (circular!)
Kết quả: phải deploy A, B, C cùng lúc = worse than monolith
3.2 ナノサービス
❌ Chia quá nhỏ:
├── ProductNameService
├── ProductPriceService
├── ProductImageService
└── ProductReviewService
✅ Chia hợp lý:
└── ProductService (gom lại thành 1 service)
3.3 共有データベース
❌ Nhiều services dùng chung DB:
Service A ──┐
Service B ──┼──► Shared PostgreSQL (products table)
Service C ──┘
Thay đổi schema → break tất cả services
✅ Database per Service:
Service A → DB_A
Service B → DB_B (replicate data nếu cần)
Service C → DB_C
4. 実践: 電子商取引プラットフォームの分離
シリーズ全体のプロジェクトに適用可能:
E-Commerce Platform Services:
┌─────────────────────────────────────────┐
│ User Service (Supporting) │
│ - Registration, Login, Profile │
│ - PostgreSQL (users, addresses) │
│ - Team: 2-3 devs │
├─────────────────────────────────────────┤
│ Product Service (Core) │
│ - Catalog, Search, Reviews, Categories │
│ - PostgreSQL + Elasticsearch │
│ - Team: 3-4 devs │
├─────────────────────────────────────────┤
│ Cart Service (Supporting) │
│ - Add/Remove items, Apply coupon │
│ - Redis (fast, ephemeral) │
│ - Team: 2 devs │
├─────────────────────────────────────────┤
│ Order Service (Core) │
│ - Place order, Track, History │
│ - PostgreSQL (orders, order_items) │
│ - Team: 3-4 devs │
├─────────────────────────────────────────┤
│ Payment Service (Generic) │
│ - Stripe/VNPay integration │
│ - PostgreSQL (transactions) │
│ - Team: 2 devs │
└─────────────────────────────────────────┘
概要
| 原則 | 説明 |
|---|---|
| ドメインごとに分割 | 技術層ごとに分割せずに DDD 境界コンテキストを使用する |
| 疎結合 | サービス A は、サービス B をデプロイする必要なく変更されます。 |
| 高い凝集力 | 関連する機能は同じサービス内にあります |
| 独自のデータ | 各サービスには独自のデータベースがあります。 |
| 適切なサイズ | 大きすぎず（モノリス）、小さすぎず（ナノサービス） |