architecture-paradigm-service-based

サービスベースアーキテクチャのパラダイム

使用する場合

• ドメインに沿ったサービスを提供する複数チームから成る組織
• コンポーネントを個別にデプロイする必要があるシステム

使用しない場合

• モノリスにするのに十分小規模な単一チームのプロジェクト
• サービス間呼び出しが許容できないほどの遅延を引き起こす、レイテンシに敏感なシステム

このパラダイムを採用する場合

• チームがある程度のデプロイの独立性を必要としているものの、多数のマイクロサービスを管理する複雑さにはまだ対応できない場合。
• 共有データベースや ERP のような大規模システムのために、完全なサービスの自律性が現実的でない場合。
• パートナーチームや外部の利用者に向けて、明確なサービス契約を確立する場合。

導入手順

1. 機能をグループ化する：関連するビジネス機能を、明確な責任者を定めた少数のサービスにまとめます。
2. サービス契約を定義する：OpenAPI や AsyncAPI などの標準を使って、サービスレベル合意（SLA）と明確なバージョニング戦略を含む正式な仕様を公開します。
3. データベーススキーマを管理する：サービス間でデータベースを共有する場合でも、各スキーマまたはテーブルの明示的な所有者を割り当てます。互換性を破る変更はすべて、正式なレビュープロセスを通すようにします。
4. サービス仲介の仕組みを確立する：サービスレジストリまたは API ゲートウェイを使用して、ルーティング、認証、可観測性を処理します。
5. 進化に備える：将来、より細かなサービスへの分割候補となる可能性が高い、アーキテクチャ上の「ホットスポット」を特定します。

主な成果物

• サービス境界、データ所有権のルール、調整の仕組みをまとめたアーキテクチャ決定記録（ADR）。
• 安定性を検証するための、各サービスのコントラクトテストおよびコンシューマー主導型コントラクトテスト一式。
• デプロイ手順、ロールバック計画、サービスの依存関係を記したランブック。

リスクと緩和策

• 共有データベースを介した結合：
  • 緩和策：共有データベースへの変更は、サービス全体に連鎖的な影響を及ぼす可能性があります。データベースビュー、レプリケーション、または正式なスキーマ廃止スケジュールを利用して変更を管理し、影響を緩和します。
• アーキテクチャの劣化：
  • 緩和策：強力なガバナンスがなければ、このアーキテクチャは「分散モノリス」、つまりネットワークホップの複雑さが加わったモノリスへと劣化する可能性があります。結合度の指標を注意深く追跡し、サービスとデータの厳格な所有権を徹底して、これを防ぎます。

具体的なコンポーネント

このパラダイムを実装するときに使われる傾向がある、ツールや抽象化の用語です。依存関係ではなく、tools: のフロントマターでもありません。

• api-gateway：粗粒度のサービスへルーティングし、横断的関心事を一元化する単一の入口
• service-registry：利用可能なサービス、ヘルスステータス、契約をまとめたディレクトリ
• schema-management：サービス境界を越える型を管理する共有スキーマリポジトリ

完了基準

• サービスを個別にデプロイする前に、サービス境界、スキーマまたはテーブルごとの明示的なデータ所有権、および調整の仕組み（サービスレジストリまたは API ゲートウェイ）をまとめた ADR がある。
• サービス間の連携箇所ごとに、バージョニングと SLA の記述を含む正式なサービス契約（OpenAPI または AsyncAPI）がある。
• 各サービスにコンシューマー主導型コントラクトテストがあり、サービス所有者がインターフェースの互換性を破る変更をマージする前に、CI でテストが通る。
• 共有データベースを介した結合のホットスポットが、スキーマ廃止スケジュールとともに文書化されている。ビューまたはレプリケーション層を介さずに、他のサービスのテーブルを読み取るサービスは、アーキテクチャ違反として指摘される。