目的地
「データ指向アプリケーションデザイン」に至る道筋
この本にたどり着くために、先に読んでおきたい本を依存関係から逆算しました。基礎から順に並んでいます。
ここまでの道筋（24冊）
なぜ先に読むのか: 正攻法の設計手順を学んだら、次は「やってはいけない設計」を反面教師から学ぶ。Bill Karwin『SQLアンチパターン』は外部キー欠如（Keyless Entry）・EAV・カンマ区切りリストなど典型的な失敗を体系化しており、制約による整合性確保の重要性を裏側から補強する。
なぜ先に読むのか: Burns の本で分散システムの「構成パターン」を学んだら、その先にあるデータの一貫性・耐障害性という難所へ。Kleppmann『データ指向アプリケーションデザイン』はレプリケーション・分散トランザクション・合意形成を理論面から掘り下げ、分散パターンを支えるデータ層の原理を与える。
なぜ先に読むのか: Go の基本的なシステムプログラミングができるようになったら、Go 最大の武器である並行処理を深く掘り下げる。Concurrency in Go は goroutine とチャネルを使った「メモリ共有ではなく通信で協調する」設計を体系立て、安全な並行プログラムの組み立て方を与える。
なぜ先に読むのか: 単一プロセス内の並行処理を理解したら、複数プロセス＝サービス間で非同期に協調する世界へ広げる。Microservices Patterns はメッセージング・Saga・イベント駆動といった分散システムの協調パターンを与え、並行性の発想をネットワーク越しに展開する。
なぜ先に読むのか: Java の文法と基本構文を一通り書けるようになったら、次は「動く」だけでなく「読める・変更しやすい」コードへ意識を引き上げる。クリーンコードは命名・関数分割・コメントの原則を与え、独学では身につきにくい品質感覚の土台を作る。
なぜ先に読むのか: 個々の関数やクラスをきれいに書けるようになったら、Java のコードで繰り返し現れる設計課題に名前のついた解法＝デザインパターンを学ぶ番だ。本書は GoF の 23 パターンを Java の実装で体感させ、再利用可能な設計の語彙とクラス間の関係を意図を持って組み立てる力を養う。
なぜ先に読むのか: クラス単位のパターンを使いこなせるようになったら、システム全体の依存の向きと境界をどう設計するかという上位の視点へ広げる。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える依存性のルールを与える。
なぜ先に読むのか: OS が提供するプロセス・I/O・メモリの仕組みを知っておくと、Spring が裏で何を抽象化しているかが見える。低レイヤーの理解はフレームワークをブラックボックスにせず、性能問題や障害の切り分けに効いてくる。
なぜ先に読むのか: Spring でひと通りアプリを組めるようになると、フレームワークに引きずられた設計（DB やフレームワーク中心）の限界に気づく。クリーンアーキテクチャはビジネスルールをフレームワークから独立させる依存性のルールを与え、長期的に変更に強い構造を選べるようにする。
なぜ先に読むのか: システム内部の境界を設計できるようになったら、その境界をプロセス＝サービスへ分割すべきかという次の判断へ進む。Monolith to Microservices は「まずモノリスから」という現実的な指針のもと、分割の動機・進め方・落とし穴を体系立てる。
なぜ先に読むのか: アーキテクチャ特性とトレードオフの語彙を得たら、その判断を分散システムという具体に適用する。マイクロサービスは独立デプロイと自律性のために、あえて結合を切る設計を要求する。
なぜ先に読むのか: 適応度関数で進化を導く発想を得たら、同じ著者陣が扱う分散アーキテクチャの難所——粒度・データ所有・通信のトレードオフ——の具体的な分析へ進む。
なぜ先に読むのか: マイクロサービスの原則を理解したら、既存モノリスからの現実的な移行戦略へ進む。多くの成功例はモノリスから段階的に切り出しており、最初から分散させない判断も含めて学ぶ。
なぜ先に読むのか: モノリスを分割すべきかの判断ができたら、実際に分割した先で必要になる実装パターンの引き出しを揃える。Microservices Patterns はサービス分割・データ管理・通信・デプロイの定石をカタログ化し、「どう分けるか」から「どう作るか」へ橋渡しする。
なぜ先に読むのか: マイクロサービスの実装パターンを学ぶと、サービス間でデータをどう一貫させるかという難所に必ず突き当たる。Designing Data-Intensive Applications は分散データの整合性・複製・トランザクションの理論を与え、パターンの「なぜ効くか」を裏付ける。
なぜ先に読むのか: 分散アーキの難所でデータ分解の判断を迫られたら、その土台となる分散データの理論へ降りる。整合性・レプリケーション・ストレージエンジンの原理が、設計判断の根拠になる。
なぜ先に読むのか: Karwin『SQLアンチパターン』が論理設計・SQL レベルの失敗を扱うのに対し、『失敗から学ぶRDBの正しい歩き方』は本番運用で顕在化する RDB の落とし穴を扱う。設計時のアンチパターンを学んだ流れで、運用時のアンチパターンへ視野を広げると、設計から運用までの失敗パターンが一望できる。
なぜ先に読むのか: 基本的な SELECT 文法を習得したら、CASE 式・ウィンドウ関数・集合演算といった「手続き型ではなく集合で考える」応用テクニックへ進むのが自然。両書とも同じ著者（ミック）による段階構成で、入門で身につけた語彙のまま応用へ橋渡しできる。
なぜ先に読むのか: 応用 SQL を書けるようになると、なぜそのクエリが速い/遅いのかをインデックスの内部構造から理解したくなる。Markus Winand『SQLパフォーマンス詳解』は B-Tree の仕組みからインデックス設計を説き起こし、SQL の「書き方」と「速さ」を一本の線で結ぶ。
なぜ先に読むのか: クエリチューニングとインデックス設計を学ぶと、性能問題の多くがスキーマや運用の初期判断に起因すると見えてくる。『失敗から学ぶRDBの正しい歩き方』は論理削除・キャッシュ・冪等性など運用全般のアンチパターンを扱い、SQL 単体の最適化から一段視野を上げてくれる。
なぜ先に読むのか: 単一のリレーショナルデータベースの設計を理解したら、複数のデータストアが絡む大規模システムの全体像へ視野を広げる。Designing Data-Intensive Applications は複製・分割・整合性・障害といったデータシステムの根本原理を、技術の流行に流されず体系化する。
なぜ先に読むのか: 『SQLパフォーマンス詳解』で RDBMS 非依存のインデックス理論を押さえたら、それが具体的な製品でどう実装されているかを『PostgreSQL徹底入門』で確かめる。B-Tree・GiST・GIN・BRIN など PostgreSQL 固有のインデックス種別やトランザクション機構に触れ、抽象理論を具体実装へ着地させる。
なぜ先に読むのか: PostgreSQL という具体的な RDBMS の実装を一つ理解すると、それを相対化する地図が欲しくなる。Petrov『詳説 データベース』はストレージエンジンや分散実装を製品横断で体系化しており、「PostgreSQL のこの仕組みは一般論ではどう位置づくか」を掴める。
なぜ先に読むのか: 単一ノードのストレージエンジン内部を理解して初めて、複数ノードに分散したときの整合性・レプリケーション・パーティショニングの議論が地に足のついたものになる。Kleppmann『データ指向アプリケーションデザイン』は分散データシステムの原理を体系化する到達点であり、内部構造の知識を必須前提（required）として据える。