前回の「分離」を、アプリ全体の形にまで広げる
前回のN-06では、部品同士の依存を弱く、部品の中身のまとまりを強く保つという、設計の良し悪しを測る2つの物差しを学びました。今回はその視点を、アプリ全体の形にまで広げます。部品を論理的に分けるだけでなく、物理的にも切り離すべきかどうか、という判断です。この講義は、その大きな選択を誤らないための地図になります。
このスライドのポイント
- N-06: 結合は弱く・凝集は強く、という設計の良し悪しを測る2つの物差し
- 今回はその視点を、部品の中ではなくアプリ全体の形へ広げる
- 論点: 部品を論理的に分けるだけでなく、物理的にも切り離すべきか
- この講義の役割: その大きな選択を誤らないための地図
モノリスとマイクロサービスの定義
まず言葉を定義します。モノリスとは、アプリ全体を1つのまとまりとして作る構成です。1つのサーバーと1つのデータベースの中に、すべての機能が同居します。これに対してマイクロサービスとは、機能ごとに独立したサービスへ分ける構成です。それぞれが自分のサーバーとデータベースを持ち、K章で学んだAPIを通じて連携します。ここで大切なのは、マイクロサービスはモノリスの上位版ではない、という点です。これは、大きな組織でチームごとに独立して動きたいという問題への解であって、技術的に進んでいるから選ぶものではありません。
このスライドのポイント
- モノリス: アプリ全体を1つのまとまりとして作る構成（1つのサーバー・1つのDBに全機能が同居）
- マイクロサービス: 機能ごとに独立したサービスへ分ける構成（各自がサーバー・DBを持ち、K章のAPIで連携）
- 重要: マイクロサービスはモノリスの上位版ではない
- 分散は「大組織でチームごとに独立して動きたい」問題への解であり、技術的に進んでいるから選ぶものではない
知らないと、複雑さを1人で抱え込む
この違いを知らないと、マイクロサービスの方が本格的だという誤解から、AIに分散構成を頼んでしまいます。ところが機能を分散させると、C章で学んだネットワーク越しの障害が持ち込まれ、K-10で見た冪等性の設計があちこちで必要になります。さらに、複数のデータベースにまたがるため、L-09のトランザクションによる整合の保証も効きません。1人の開発では、この複雑さは運用できない重荷になります。
このスライドのポイント
- 誤解: 「マイクロサービスの方が本格的」→ AIに分散構成を頼んでしまう
- 分散が持ち込む代償:
2構成の対比と、複雑さの表
図の左に、1つの箱にまとまったモノリスを、右に、複数の箱へ分かれたマイクロサービスを置いて比べます。分散させると、変更の反映も、障害の調査も、データの整合も、すべてが難しくなります。小規模な開発の正解は、モノリスという1つのまとまりを保ちながら、その中身をN-05の責任分離とN-06の結合度・凝集度で綺麗に整えることです。外側を1つに保ったまま、内側を論理的に分けるのです。
このスライドのポイント
- 左: 1つの箱のモノリス／右: 複数の箱のマイクロサービス
- 分散させると、変更の反映・障害調査・データ整合が、すべて難しくなる
経費精算アプリを4サービスに分けた場合の悲劇
経費精算アプリを、申請・履歴・承認・通知の4つのサービスに分けたと想像してください。申請の保存と履歴の記録が別々のデータベースに離れると、L-09の1つのトランザクションでまとめて確定させることができません。片方だけ成功して片方が失敗する事態に備え、K-10の冪等性の設計をすべての接続点で用意する羽目になります。モノリスなら、この保存と記録は1つのトランザクションで一度に済みます。
このスライドのポイント
- 経費精算アプリを「申請・履歴・承認・通知」の4サービスに分けたと想像する
- 申請の保存と履歴の記録が別DBに離れる → L-09の1つのトランザクションでまとめて確定できない
- 片方だけ成功・片方が失敗に備え、K-10の冪等性の設計を全接続点で用意する羽目に
- モノリスなら、保存と記録は1つのトランザクションで一度に済む
技術サンプル: 構成の判断基準表
構成を選ぶときは、判断軸を並べて確かめます。チーム人数、独立して更新・公開する必要があるか、運用を誰が見るか。この3つを表にすると、1人から小さなチームの開発では、すべての行がモノリス側を指します。分散構成が力を発揮するのは、人数と組織が大きくなり、チームごとに別々に動きたくなってからです。AIには、いまの規模でマイクロサービスにする合理性があるか、モノリスで困る具体的な時点はいつかを尋ねて、必要性を確かめてください。
このスライドのポイント
- 種別: table
- 目的: いまの規模で、モノリスとマイクロサービスのどちらを選ぶかを判断軸で確かめる
- サンプル本体（判断基準表）:
混同しやすい: 分離されたモノリスとマイクロサービス
混同しやすいのが、よく分離されたモノリスと、マイクロサービスの違いです。前者は、N-05の層が綺麗に整った1つのまとまりです。後者は、それを物理的に別々のサービスへ切り離したものです。分ける論理は同じで、物理的に切り離すかどうかだけが違います。そして実際には、綺麗に分離されたモノリスで足りる場面が大半です。
このスライドのポイント
- よく分離されたモノリス: N-05の層が綺麗に整った、1つのまとまり
- マイクロサービス: それを物理的に別々のサービスへ切り離したもの
- 分ける論理は同じ／物理的に切り離すかどうかだけが違う
- 実際には、綺麗に分離されたモノリスで足りる場面が大半
バイブコーディングでの確認点
AIが分散構成を提案してきたら、すぐに受け入れず、その分割で失うものを挙げさせてください。1つのトランザクションによる整合や、障害調査のたやすさは、分散すると手放すことになります。失うものを並べたうえで判断する——これは次回以降のN-10で学ぶトレードオフの考え方の予行でもあります。
このスライドのポイント
- AIが分散構成を提案してきたら、すぐ受け入れず「その分割で失うもの」を挙げさせる
- 失うものの例: 1つのトランザクションによる整合、障害調査のたやすさ
- 失うものを並べたうえで判断する＝N-10で学ぶトレードオフ思考の予行
- 質問例: 「この分割で失うもの（トランザクション・調査の容易さ）をすべて挙げてください」
一問一答とまとめ
最後に一問一答です。小規模な開発の定石は、モノリスとマイクロサービスのどちらでしょうか。（間）答えはモノリスです。中身を責任分離で綺麗に保ちながら、外側は1つのまとまりに保つ——これが「小規模はモノリスから」という定石です。理由は、分散が持ち込む障害・整合・調査の複雑さを、小さな体制では運用しきれないからでした。30秒でまとめます。モノリスは1つのまとまり、マイクロサービスは分散、後者は大組織の解であって上位版ではありません。次回は、処理を待たせるか裏で回すかを決める、同期と非同期の設計判断へ進みます。関連資料は「Webアプリ構成図入門」と「AI開発ツール別の向き不向き」です。
このスライドのポイント
- 一問一答: 小規模開発の定石は、モノリスとマイクロサービスのどちらか
- 答え: モノリス（中を責任分離で綺麗に保つ）
- 30秒まとめ: モノリス＝1つのまとまり／マイクロサービス＝分散／後者は大組織の解であって上位版ではない
- 次回: 同期と非同期の設計判断（N-08）
- 関連資料: 「Webアプリ構成図入門」「AI開発ツール別の向き不向き」
