要点: Microservicesは組織と運用の選択肢であり、大規模システムの必須目標ではありません。
この記事の用語: Modular Monolith：一アプリケーション内を明確なモジュールへ分ける設計。サービス境界：サービスの責任範囲。
現場の課題
技術レイヤーごとに分割すると、一つの要求が多数のサービスを通ります。リリース調整は残ったまま、ネットワーク障害と分散トランザクションだけが増えます。
サービス境界の価値は、チームが独立して所有、リリース、スケールできることです。Modular Monolithなら、ネットワークと分散トランザクションのコストを払う前に境界を安く検証できます。
設計と実装
- 業務能力、データの不変条件、変更を所有するチームを整理します。
- Modular Monolith内でモジュールAPIと依存ルールを強制します。
- 一つの業務能力を、API契約、データ移行、ロールバック手順と一緒に分離します。
実装例
module Orders exposes OrdersApi
module Billing exposes BillingApi
Orders may call BillingApi
Orders must not import BillingRepository
architectureTest.assertNoInternalDependencyLeaks()本番導入の進め方
アーキテクチャテストと担当者が明確なモジュールから始めます。読み取り、書き込み、データの順に分離し、運用上の利益が分散コストを上回るときだけ独立サービスへ移します。
まとめ
良いサービス境界はチーム間の調整を減らし、悪い境界は関数呼び出しをネットワーク呼び出しへ変えるだけです。