PR：この記事にはアフィリエイトリンクが含まれます。
モジュラーモノリスの設計では、変更のまとまりをどこで区切り、依存関係をどちらへ流すかが先に問われます。サービスの数を決めるのはその後。境界が見えると、設計の話も具体的になります。
ソフトウェアアーキテクチャの本には、マイクロサービスを扱うものが目立ちます。けれど既存システムでは、モジュール境界や依存の乱れが早く課題に上がることも。4冊の得意分野を押さえながら、実務で使える設計の視点を整理します。
本の全体像
まずは4冊のテーマを一覧にしました。モジュラーモノリスの基礎から、分散化、アーキテクチャの計測まで、扱う課題はそれぞれ異なります。
| 書名 | 主なテーマ | ページ数・発行年 | 参考価格（税込） |
|---|---|---|---|
 ソフトウェアアーキテクチャの基礎 第2版 | モジュール、結合、設計全体 | 560ページ・2026年 | 4,950円 |
 ソフトウェアアーキテクチャ・ハードパーツ | 境界と設計上のトレードオフ | 472ページ・2022年 | 4,180円 |
 ソフトウェアアーキテクチャメトリクス | 指標と改善の優先順位 | 276ページ・2024年 | 3,300円 |
 モノリスからマイクロサービスへ | 分割と段階的な移行 | 276ページ・2020年 | 3,520円 |
価格は税込の公式希望小売価格を目安にしています。実際の販売価格は時期や店舗で変わるため、購入時に店頭やオンライン書店で確認してください。
設計の全体像には基礎書、境界にまつわる難しい判断にはハードパーツが頼りになります。現状の測定ならメトリクス、運用中のモノリスの移行ならNewmanの本が具体的です。
境界を決める軸
モジュールの境界は、フォルダーやクラスの配置だけで決まるものではありません。同じ理由で変わる機能をまとめ、別の理由で変わる機能は分ける。業務のまとまりと変更のまとまりを重ねて考えます。
注文処理を例にすると、注文の状態管理と在庫の更新は近く見えるかもしれません。けれど、在庫の予約や解放は在庫側、注文の受付や取消は注文側が責任を持つ形に分けられます。データの近さより、業務上の責任が境界を決める手掛かりですね。
細かく分ければよいわけでもありません。ひとつの変更で毎回いくつものモジュールを直すなら、分割が細かすぎるか、責任の置き方がずれている可能性があります。何でも共通モジュールへ集めると依存が集中し、変更の影響も広がります。
境界を考えるときは、変更理由、データの所有者、守るべき業務ルールを並べてみましょう。返金条件が変わるなら、どのモジュールの知識が変わるのか。具体的な変更を思い浮かべると、機能一覧より判断しやすくなります。
モジュラーモノリス
モジュラーモノリスは、ひとつのアプリケーションとして動かしながら、内部を明確なモジュールに分ける構成です。デプロイや運用はひとつのまま、コードの責務と依存関係を整理できます。境界設計を実践しながら学ぶ場にもなるでしょう。
基本は、各モジュールが自分のデータを所有し、他のモジュールは決められた窓口から利用する形です。注文モジュールから在庫モジュールの予約窓口を呼び出せば、在庫のルールを一か所で守れます。
モジュール名を付けただけでは境界は保てません。どこからでも内部のクラスやテーブルを参照できるなら、実態は大きなひとつの塊です。公開する窓口を絞り、禁止した依存をコード検査などで見つけられると、日々の変更から設計を守りやすくなります。
モジュール間のやり取りを、最初からイベントや複雑な抽象層で埋め尽くす必要はありません。直接呼び出す場合でも、依存の向きとデータの所有者を明確にすること。境界を越える変更が続く場所を見直し、必要に応じて通信方法を増やせば十分です。
依存関係を整える
依存関係を見れば、どのモジュールが別のモジュールの詳細を知っているかが分かります。利用される側の実装変更が利用する側まで伝わるほど、結合は強い状態です。目指すのは変更の広がりを抑えること。
依存の向きを図に描くと、循環や集中に気づきやすくなります。AがBを呼び、BがCを呼び、CがAに戻る。そんな状態では、どこを直すにも全体を気にしなければなりません。まず循環をほどき、業務上の窓口を持つ側に責任を置きましょう。
共通コードの扱いにも気を配りたいところです。日付や文字列のような汎用処理は共通化しやすい一方、複数業務のルールを集めたモジュールには変更が集中しがち。似ていることに加え、同じ理由で変更されるかも共通化の基準にします。
モジュール間でデータを共有するなら、読み取りと更新を分けて考えます。他モジュールのテーブルへ直接書き込めると、データの所有者が曖昧になり、整合性を守る責任も分散します。更新を所有者の窓口に寄せ、必要な情報だけを公開すると、依存関係を見通しやすくなります。
基礎を一冊で
ソフトウェアアーキテクチャの基礎 第2版は、Mark RichardsとNeal Fordによる560ページの本です。オライリー・ジャパンから2026年に発行され、参考価格は税込4,950円。設計から構築、維持まで幅広く扱います。
モジュールと結合の基礎に加え、複数のアーキテクチャスタイルをトレードオフとともに学べます。第2版ではモジュラーモノリスの解説も追加されました。実践例を交え、ひとつのアプリケーション内で境界を設計する考え方に触れられます。
境界設計に初めて取り組む開発者が、全体像をつかむ際の第一候補です。移行手順より設計の選択肢や判断軸を学びたいなら、この本をおすすめします。
難所の判断材料
ソフトウェアアーキテクチャ・ハードパーツは、Neal Ford、Mark Richards、Pramod Sadalage、Zhamak Dehghaniの共著です。2022年発行、472ページで、参考価格は税込4,180円。モジュールやサービスの粒度など、正解がひとつとは限らない課題を扱います。
結合の見分け方、データ所有権、契約の管理、分散トランザクションなどを、複数の選択肢とトレードオフから考えます。モノリスを分解してマイクロサービスへ再構築する例もあり、境界を動かすと何が難しくなるのかを具体的に追えます。
境界の候補が複数あり、設計判断の影響をチームで話し合いたい人におすすめです。基礎を押さえ、データやサービスを分割する際の複雑さまで検討する段階で役立ちます。
指標で改善を見る
ソフトウェアアーキテクチャメトリクスは、10人のアーキテクトによる事例をもとにした276ページの本です。2024年発行で、参考価格は税込3,300円。アーキテクチャの状態を指標で捉え、改善の優先順位を考えます。
モジュール性成熟度指数では、モジュール性や階層性、パターンの一貫性などを評価します。適応度関数を使って品質や技術的負債を測る方法も扱います。指標は、優先する改善箇所と成果を確かめるために使います。
改善の着手点を決めたい開発者やアーキテクトにおすすめです。指標の選定や技術的負債の優先順位付けを学ぶなら、基礎書に続けて読む価値があります。
移行を段階で進める
Sam Newmanのモノリスからマイクロサービスへは、2020年発行、276ページです。参考価格は税込3,520円。凝集と結合、境界づけられたコンテキスト、モノリスを分割するときの論点を扱います。
コードやデータベースの分割に加え、データ所有権の移行や、業務を続けながら移行する方法も学べます。既存機能を段階的に置き換えるストラングラーアプリケーションなど、具体的な移行パターンも取り上げています。
運用中のモノリスを止めずに整理・移行したい人には、とくに実用的な一冊です。境界設計全般より、分割の計画やデータ移行が目の前の課題なら、内容が実務に直結するでしょう。
結論
モジュラーモノリスの実践で大切なのは、各モジュールの責任と依存の向きを明確にすることです。数を増やすだけでは十分ではありません。業務ルールとデータの所有者を定め、境界をコード上の制約として保てば、変更の影響を抑えやすくなります。
設計の全体像にはソフトウェアアーキテクチャの基礎 第2版、難しい設計判断にはソフトウェアアーキテクチャ・ハードパーツが有力です。改善の測定ならソフトウェアアーキテクチャメトリクス、運用中のシステムを段階的に移すならNewmanの本が役立ちます。
最初の一冊なら、モジュラーモノリスと境界設計をひと続きで学べる第2版をおすすめします。移行や計測など、すでに課題がはっきりしている場合は、そのテーマの本から読むと実務に早くつながります。
Amazon の PC をスコア化してみた
Amazonにある8〜14インチの小型WindowsタブレットやノートPCを、スペック別にスコア化して比較・ランキング。
