MSAを整える。

MSA（マイクロサービスアーキテクチャ）は、1つの大きなアプリケーションを、機能ごとに独立してデプロイできる小さなサービスの集合として作る設計の考え方です。各サービスは自分の担当範囲（例：会員・決済など）に責任を持ち、他のサービスとはネットワーク越しの通信（多くはAPI呼び出し）でやり取りします。

対になる考え方がモノリス（モノリシックアーキテクチャ）で、こちらは全機能を1つのプログラム・1つのデプロイ単位としてまとめて作る、より古くからある形です。上のシミュレーターで「① 1つのモノリスにまとめる」を選ぶと、この状態を体感できます。特定の会社や書籍が最初に発明した用語というより、大規模なWebサービスの実務の積み重ねから、一般的な技術文献で整理されるようになった考え方だとされます。

モジュラーモノリスは、デプロイ単位は1つのまま（＝モノリス）で、内部のコードをモジュールごとにきっちり分け、モジュール間の呼び出しルールを決めておく作り方です。「機能ごとの境界を意識する」というマイクロサービスに近い恩恵の一部を、ネットワーク通信や運用対象の増加といったマイクロサービスの手間を増やさずに得ようとする、中間的な選択肢としてしばしば紹介されます。

注意点：本シミュレーターの「箱」は、あくまでデプロイ単位（本番にどう配る一塊か）の境界を表しています。モジュラーモノリスは内部のコード構造（モジュール境界）の話なので、デプロイ単位で見ると素朴なモノリスと同じ「1箱」になり、このシミュレーター上では区別がつきません。モジュールの境界の良し悪しそのものは、コードの内部構造を見ないと分からない、という限界があります。

最初からすべてを細かいサービスに分けるのではなく、まず1つのまとまり（モノリスやモジュラーモノリス）として作り始め、チームの人数やサービスの規模が大きくなった段階で、必要な境界だけを見極めて分けていく、という進め方がしばしば紹介されます。上のシミュレーターでいえば、まず「① 1つのモノリス」から出発し、必要に応じて「② 2つのサービス」「③ 全部バラバラ」へと段階的に動かしていくイメージです。

ただし、これも唯一の正解というわけではなく、事業の立ち上げ方やチーム構成によっては、最初から一定の分割を選ぶ現場もあります。分割は通信線・独立デプロイ・障害の影響範囲といったトレードオフを伴う判断であり、流派・現場により重視する軸が異なる、という前提でこのシミュレーターを使ってみてください。

DDD（ドメイン駆動設計）の「境界づけられたコンテキスト」（業務上の意味が閉じたひとまとまりの範囲）が、MSAでサービスを分割する際の単位の候補になりうる、とされます。ただし、これも流派・現場によって判断が分かれる通説であり、境界づけられたコンテキスト＝サービスと機械的に対応させるべきだと断定するものではありません。境界づけられたコンテキストの考え方そのものは「DDDを整える」で扱っています。