質問
独立デプロイ可能性に基づいた開発の単位はどのようにあるべきでしょうか。 Tipsをください。 |
解答
「独立デプロイ可能性（Independent Deployability）」を基準に開発単位を決める、いわゆる マイクロサービス指向 または 疎結合アーキテクチャ に関するとても本質的な質問です。 以下では、 * どのような単位で区切るべきか * 具体的な判断基準 * そして実務で使える Tips を整理します。 # 1. 原則：変更の理由（変更理由の単一性）で区切る 独立デプロイ可能であるということは、 > あるコードが変更されたときに、その変更は「そのサービスだけ」で完結しなければならない > ということです。 そのため、開発単位は 「変更が一緒に発生するものを一つにまとめる」 という軸が最も重要です。 逆に言えば、 「同時に変更されないものを同じコンテキストに入れるのは間違い」 です。 # 2. 具体的な境界（サービス分割の基準） (1) ビジネス領域（ドメイン）ごとに分ける DDD（ドメイン駆動設計）の境界づけられたコンテキストを参考にします。 例：ECサイト * 商品管理（Catalog） * 注文管理（Order） * 決済（Payment） * 顧客（Customer） 変更理由がまったく違います。 (2) データが共有されないようにする 独立デプロイを阻害する最大の原因は「同一DBを共有すること」です。 各サービスごとにDBスキーマを分けるのが理想。 (3) スケール・負荷特性が異なる部分を分ける * 商品検索はCPU負荷が高い → 独立スケール * 注文管理はI/O中心 → 別でよい 負荷特性が違うものを同じサービスに入れる必然性はありません。 (4) チーム構造（Conwayの法則）に合わせる チーム A と B が別々に開発するなら、サービスも分けるべき。 > 組織構造がシステム構造を決める > という有名な原則です。 (5) 依存関係が一方向になるように 循環依存がある場合、その2つは独立デプロイできません。 # 3. 避けるべきアンチパターン * 「モデルを共有する」 * 「DBを共有する」 * 「共通ライブラリに大量のロジックを移す」 * 「1サービスが別サービスの内部構造を知っている」 どれも独立デプロイ可能性を崩す典型例です。 # 4. 実務 Tips（実際に役立つ指針） Tips 1：サービスは「ビジネス上の契約（API）」を中心に設計する 内部実装を隠し、REST/GraphQL/gRPC の契約だけ公開する。 Tips 2：サービス間を「同期」で結ばない 同期通信（REST → REST）は依存を強くするので、 できれば 非同期（イベント駆動） を検討する。 Tips 3：コードベースは完全に独立させる 「モノレポでもよいが依存関係は完全に独立」が理想。 Tips 4：サービスの大きさは「2週間で書き換えられる」程度 大きすぎると独立デプロイの価値が薄れます。 Tips 5：境界を間違えても良い。 後で分割できるように設計する * API Gateway を通す * DBは最初から論理分割しておく これで後からサービスを分割できます。 Tips 6：1サービスに「複数の責務」が見えたら分割を検討する 以下が混ざっていると危険です。 * 認証 * 決済 * ログ収集 * 監視 * ファイルストレージ * フロント配信 1つにまとめると運用で破綻します。 # 5. 独立デプロイ可能性のゴール 最終的には次のような状態を目指します。 * 各サービスは独立してビルド・テスト・デプロイできる * あるサービスのデプロイが他サービスの動作に影響しない * 契約（API）が安定していて互換性が担保される * チームが並行で開発できる 「サービスの境界＝ビジネス境界」 の状態がもっとも健全です。 |
 |
 |
この記事へのコメント