設計（アーキテクチャ）

モノリスは、アプリ全体を1つのコードベース・1つのデプロイで動かす形、マイクロサービスは、機能ごとに小さなサービスに分け、それぞれを別にデプロイし、ネットワーク越しに呼び合う形です。

分けたときに増える運用の負担

• サービスごとの CI/CD・監視・アラート・ログ・ダッシュボード・担当者。
• ネットワーク越しの呼び出しの失敗への備え（タイムアウト・リトライ・サーキットブレーカー）と、遅延の積み重なり。
• API の互換性の管理（片方だけ先にデプロイしても壊れないように）。
• サービス間の認証、分散トレース、ローカルでの開発環境の再現。
• データが分かれるので、集計や JOIN ができず、整合性を取る仕組みが要る。

多くの場合は、中をモジュールにきちんと分けたモジュラーモノリスで始め、チームの独立性や特定の機能の負荷など、分ける理由がはっきりした所から切り出すのが現実的です。

モジュラーモノリスでは、モジュールの間は公開した関数（インターフェース）だけで呼び、他のモジュールの表を直接読まない、というルールを決めます。こうしておくと、あとで1つのモジュールを別のサービスに切り出すときの作業が小さくなります。

サービスごとに DB が分かれると、1つのトランザクションで「注文を作り、在庫を減らし、決済する」ことができません。Saga は、各サービスのローカルなトランザクションを順につなぎ、途中で失敗したら、それまでの手順を取り消す補償の処理を流す考え方です。

• 途中の状態（「注文は作ったが決済はまだ」）が外から見えるので、画面やステータスで表す。
• メッセージは2回届くことがあるので、各手順と補償の処理は冪等に作る。
• イベントの送信は Outbox パターンで DB の更新とずらさない。

SRE の「分散トランザクションとデータ整合性」

コードを役割ごとの層（レイヤー）に分けると、変更の影響が広がりにくくなり、テストもしやすくなります。よくある分け方は次のとおりです。

やりすぎない

小さなアプリや、ほとんどが「DB に保存して表示するだけ」の画面に、層やインターフェースを何重にも作ると、1つの項目を足すのに5つのファイルを直すことになります。

• まずはフレームワークの標準の形に従う（Rails の MVC など）。
• 業務のルールが複雑な所（料金・在庫・権限）から、ドメインの層を分ける。
• テストで差し替えたい外部（決済・メール）だけインターフェースにする。
• 「後で必要になるかも」で抽象化しない。必要になったときに分ける。

• クリーンアーキテクチャ（ヘキサゴナル・オニオンも同じ考え）：依存の向きを内側（業務のルール）に向ける。ドメインは DB やフレームワークを知らず、インフラ側がドメインの決めたインターフェースを実装する。DB を替えても業務のルールは変わらず、テストで DB を差し替えられる。
• DDD（ドメイン駆動設計）：業務の言葉をそのままコードの名前に使い（ユビキタス言語）、業務の区切り（境界づけられたコンテキスト）でモジュールを分ける。同じ「顧客」でも、請求と配送では持つ情報が違う、のように考える。