このレッスンをすべて読み終えると、以下の3つを自信を持って実践できるようになります。

• ▸✅ モノリス vs MSA の判断基準5項目チェックリスト
• ▸✅ mermaid を使ったシステム図の可視化
• ▸✅ 関心事の分離 (Presentation · Domain · Data)

学習目標をチェックリストとして手元に置き、すべて答えられるようになったらレッスンを閉じてください。

MSA (Microservices Architecture) vs モノリス:

メッセージキュー — 非同期通信:

API Gateway — MSA の単一エントリーポイント:

• ▸ルーティング (リクエスト → 適切なサービスへ)
• ▸認証·認可 (各サービスで重複させない)
• ▸レート制限·キャッシング·ロギング
• ▸代表例: Kong·AWS API Gateway·Envoy·Traefik

> 💡 MSA はいつ?: チーム8名以上 · トラフィックがドメインごとに大きく異なる場合。それまではモノリス → モジュール化 → 抽出。

Event Sourcing — 状態ではなくイベントを保存

• ▸従来方式: users テーブルの行を更新
• ▸ES: events テーブルに UserCreated·EmailChanged を追記 (不変)
• ▸現在の状態 = すべてのイベントを再生 (replay)

メリット:

• ▸完全な監査ログ (誰が·いつ·何をしたか)
• ▸タイムトラベル (過去の状態を再現)
• ▸新しい読み取りモデルを追加しやすい

デメリット:

• ▸複雑性の増加 (単純な CRUD と比較して)
• ▸イベントスキーマの変更が難しい (イベントは不変)
• ▸学習曲線が急峻

CQRS (Command Query Responsibility Segregation):

• ▸Command (書き込み) — 正規化された DB、トランザクション
• ▸Query (読み取り) — 非正規化·キャッシュ·検索エンジン

例: ショッピングモール

• ▸Command: PostgreSQL (注文処理·決済)
• ▸Query: Elasticsearch (商品検索)、Redis (キャッシュ)
• ▸同期: Kafka で変更イベントを配信

適している場面:

• ▸🟢 読み取り/書き込み比率の差が大きい (例: 10000:1)
• ▸🟢 複雑な検索·集計
• ▸🔴 単純な CRUD → オーバーキル

> 💡 ES + CQRS = よく一緒に使われる。イベント → 複数の読み取りモデルに変換。

現代における活用例:

• ▸Banking: ES が標準 (監査·規制対応)
• ▸E-commerce: 注文ドメインのみ ES を適用
• ▸Gaming: プレイヤーアクションの記録

核心の一言

AI に「MSA で作って」とだけ伝えると、モノリスをただ分割するだけになります。本物の MSA ではなく、分散モノリス (最悪の形態) が出来上がります。

なぜ AI だけではアーキテクチャが決まらないのか

LLM はコードパターンを学習しているだけで、ビジネスドメインは理解していません。サービス境界がどこにあるか、どの情報を誰が所有するかは人間が決定しなければなりません。

❌ 悪いプロンプト:
> 「このモノリスを MSA に分割して」

→ AI: User Service、Order Service、Payment Service... 単純な分離。
→ 結果: サービス間の循環呼び出し + トランザクション破綻 — 本物の分散モノリス。

✅ 良いプロンプト:
> 「以下のビジネス境界で MSA を設計して:
> - Auth Service: ユーザー認証·セッション。他のサービスはJWT のみを受け取る
> - Order Service: 注文フロー。Payment とはイベント経由で通信 (密結合は NG)
> - Notification Service: 通知。他のサービスはKafka トピックにパブリッシュ
>
> ACID トランザクションが必要な箇所: 決済。Saga パターンを使用。」

→ AI: 明確な境界で本物の MSAを実装。

判断チェックリスト — 自分のプロジェクトはモノリス？MSA？

5 問 (各 0〜2 点、合計 10 点):

• ▸0〜3点 → モノリス。他のことは気にしない。Next.js + DB 一つから始める
• ▸4〜6点 → モジュール境界を明確にしたモノリス。将来の分離に備える
• ▸7〜10点 → MSA を検討。ただし、モノリスから始めて、問題が発生した部分だけ分離を推奨

「まずモノリスから」という真理

> "If you can't build a monolith, what makes you think microservices is the answer?" — Simon Brown

95% のスタートアップは、モノリス + しっかりと分離されたモジュールで十分です。MSA は明確なペインポイントがあるときだけ。

落とし穴 — MSA の隠れたコスト

スタートアップ段階での MSA = 時間とお金の無駄。Toss・クーパン レベルのトラフィックになってから検討しましょう。

AI にアーキテクチャを聞くパターン

❌ 「MSA とモノリスはどちらが良いですか?」 — 抽象的すぎる

✅ 「私のプロジェクトはチーム3名·1日5千ユーザー·週1デプロイ·Node.js 単一スタックです。この状況で MSA は意味がありますか？チェックリストに基づいて分析してください。」

→ AI が自分の状況に合った回答を返してくれる。

まとめ

• ▸AI はコードパターンしか知らない。ビジネス境界は人間が決める
• ▸5問チェックリストで自分の状況を診断する
• ▸まずモノリスから。MSA は本当に必要なときだけ
• ▸AI に質問するときは具体的な状況を明示する

このレッスンの概念を知っていれば、AI に具体的に指示できます。漠然とした「直して」ではなく、語彙を持ったリクエスト — それがトークン節約の出発点です。

• ▸「このモノリスを MSA に分割する前に、5点チェックリストで確認して」
• ▸「このシステム図を mermaid で描いて」

なぜこれがトークンを減らすのか

概念を知らないと、AI の回答を受け取っても「それは何ですか?」と再度聞かなければなりません。その「再質問」がトークンを消費します。概念を一度理解しておくと、会話が一往復で完結します。