『DDD + マイクロサービス』は設計の王道
DDD の Bounded Context をマイクロサービス境界に落とし込むのは、現代的な設計の王道です。本記事では編集部の視点で、設計手順を公開情報をもとに整理します。DDD 実践 もご参考に。
サービス分割の3ステップ
(1) ドメイン分析：イベントストーミング。(2) Bounded Context の特定。(3) Context Map 作成。(4) サービス境界の決定。(5) API 契約の設計。マイクロサービス設計 もご参考に。
イベントストーミング
(1) ビジネスイベントの抽出。(2) コマンド/集約/ポリシーの識別。(3) 付箋ベースのワークショップ。(4) 関係者全員参加。(5) Miro/FigJam 等のツール。
Bounded Context の判別
(1) 用語の意味が変わる。(2) 独立性が高い。(3) 変更頻度が異なる。(4) 所有チームが違う。(5) データ整合性の単位。
Context 間の関係パターン
(1) Customer/Supplier：上下流。(2) Conformist：上流に従う。(3) Anti-Corruption Layer：腐敗防止層。(4) Open Host Service：公開API。(5) Shared Kernel：共通モデル。
サービス間通信の設計
(1) 同期 (gRPC/REST)。(2) 非同期 (Event)。(3) Saga パターン：分散トランザクション。(4) CQRS：読み書き分離。(5) Event Sourcing：状態の事実積み上げ。イベント駆動 もご参考に。
サービス境界の見直し
(1) 2〜3年で再評価。(2) 密結合サービスは統合。(3) 巨大サービスは分割。(4) テックリードのオーナーシップ。(5) 段階的リファクタ。技術的負債管理 もご参考に。
失敗しがちなパターン
(1) 技術中心の分割：ドメイン無視。(2) 細かすぎ：通信オーバーヘッド大。(3) 共通DB：分離の意味喪失。(4) Shared Kernel 肥大。(5) Saga の複雑性軽視。対策は、(1)ドメイン優先、(2)1サービス1チーム目安、(3)DB 完全分離、(4)Shared最小化、(5)Saga専門知識、です。