Domain
バックエンド開発
API設計からサーバーサイドアーキテクチャ、認証・認可、非同期処理、 分散システム、パフォーマンス最適化まで、バックエンド開発の実装力と 設計原則を体系的に養うための学習パス。
この分野の地形
バックエンドの地形は、海岸の低地から内陸の高山へと登っていく 一つの大陸として描ける。出発点となる海岸線は「言語と品質」の登り口。 動くコードを書く力（言語の基礎）から、読みやすく変更に強いコードへと 意識を引き上げる土台がここにある。
中腹で道は二つの尾根に分かれる。一方は TCP/IP から Web API・認証へと続く 「通信とインターフェース」の尾根。もう一方はクラス設計（デザインパターン）から システム全体の依存設計（クリーンアーキテクチャ）へと至る「設計」の尾根。 二つは独立に登れるが、フレームワークという峠で合流する。
内陸の奥には、単一サーバーを越えた「分散・データ・安定性」の山脈がそびえる。 モノリスからマイクロサービスへの分割判断、その実装パターン、障害に耐える設計、 そしてデータ指向設計の最高峰へ。この分野を俯瞰する鍵は、足元の一行から 大規模運用まで、関心事のスケールが連続して繋がっている点にある。
矢印の向きに読み進めます／実線＝必須・破線＝推奨
この地図を共有
グループ化
難易度
難易度
依存関係
グラフを計算中...
収録書籍
28件
スッキリわかるJava入門
中山清喬, 国本大悟
マスタリングTCP/IP 入門編 第6版
井上直也、村山公保、竹下隆史、荒井透、苅田幸雄
リーダブルコード
より良いコードを書くためのシンプルで実践的なテクニック
Dustin Boswell, Trevor Foucher
Clean Architecture
達人に学ぶソフトウェアの構造と設計
Robert C. Martin
Clean Code
アジャイルソフトウェア達人の技
Robert C. Martin
Web APIの設計
The Design of Web APIs
Arnaud Lauret
Goならわかるシステムプログラミング 第2版
渋川よしき
初めてのGraphQL
Learning GraphQL
Eve Porcello、Alex Banks
ふつうのLinuxプログラミング 第2版
Linuxの仕組みから学べるgccプログラミングの王道
青木峰郎
達人プログラマー
熟達に向けたあなたの旅 第2版
David Thomas, Andrew Hunt
プロを目指す人のためのTypeScript入門
安全なコードの書き方から高度な型の使い方まで
鈴木僚太
失敗から学ぶRDBの正しい歩き方
曽根壮大
Spring徹底入門
Spring FrameworkによるJavaアプリケーション開発
株式会社NTTデータ
Web APIテスト技法
Testing Web APIs
Mark Winteringham
単体テストの考え方/使い方
Vladimir Khorikov
Web API: The Good Parts
水野貴明
Webを支える技術
HTTP、URI、HTML、そしてREST
山本陽平
Go言語による並行処理
Concurrency in Go
Katherine Cox-Buday
Java言語で学ぶデザインパターン入門
結城浩
データ指向アプリケーションデザイン
信頼性、拡張性、保守性の高い分散システム設計の原理
Martin Kleppmann
ドラゴンクエストXを支える技術
大規模オンラインRPGの舞台裏
青山公士
gRPCアップアンドランニング
gRPC: Up and Running
Kasun Indrasiri、Danesh Kuruppu
マイクロサービスパターン
Microservices Patterns
Chris Richardson
モノリスからマイクロサービスへ
モノリスを進化させる実践移行ガイド
Sam Newman
OpenID Connect入門
アプリケーション開発者のための実践技術解説
土岐孝平
エンタープライズ アプリケーションアーキテクチャパターン
Patterns of Enterprise Application Architecture
Martin Fowler
実践 AIエージェント開発
マルチエージェントシステムの設計と実装
Michael Albada
Release It!
本番用ソフトウェア製品の設計とデプロイのために 第2版
Michael T. Nygard
依存関係
理由: Java の文法と基本構文を一通り書けるようになったら、次は「動く」だけでなく「読める・変更しやすい」コードへ意識を引き上げる。クリーンコードは命名・関数分割・コメントの原則を与え、独学では身につきにくい品質感覚の土台を作る。
理由: 個々の関数やクラスをきれいに書けるようになったら、Java のコードで繰り返し現れる設計課題に名前のついた解法＝デザインパターンを学ぶ番だ。本書は GoF の 23 パターンを Java の実装で体感させ、再利用可能な設計の語彙とクラス間の関係を意図を持って組み立てる力を養う。
理由: Java の基礎が固まれば、実務のサーバーサイド開発で標準的に使われる Spring Framework へ進む。DI・AOP・MVC といった枠組みは素の Java の知識を前提とするため、言語の理解を土台にフレームワークの抽象を一段ずつ載せていく。
理由: クラス単位のパターンを使いこなせるようになったら、システム全体の依存の向きと境界をどう設計するかという上位の視点へ広げる。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える依存性のルールを与える。
理由: TCP/IP と HTTP の動作原理を理解すると、その上に成り立つ REST API の設計判断が「なぜそうするか」まで腑に落ちる。Web API The Good Parts は HTTP の意味論を踏まえた URI・メソッド・ステータスコードの実践的な設計指針を与える。
理由: ネットワークの仕組みを掴んだら、その通信を実際に処理する OS の層へ降りる。Linux のシステムプログラミングはソケット・プロセス・ファイルディスクリプタといった、サーバーが動く土台の API を与え、プロトコルと実装の橋を架ける。
理由: プロトコルの理解を、実際に動くサーバーの実装へつなげる段階。Go によるシステムプログラミングは並行性に強い言語でネットワークサービスを書く具体を与え、TCP/IP の知識をコードに落とし込む経験を積ませる。
理由: OS が提供するプロセス・I/O・メモリの仕組みを知っておくと、Spring が裏で何を抽象化しているかが見える。低レイヤーの理解はフレームワークをブラックボックスにせず、性能問題や障害の切り分けに効いてくる。
理由: 素のシステムプログラミングでサーバーを書く苦労を一度味わうと、Spring のようなフレームワークが何を肩代わりしているかが実感として分かる。低レイヤーの経験は、フレームワークの便利さと制約を相対化する視点を与える。
理由: REST の基本的な設計指針を身につけたら、API を「契約」として記述・共有する実践へ進む。The Design of Web APIs は OpenAPI による仕様駆動の設計プロセスを示し、場当たりでない一貫した API を組織で作るための型を与える。
理由: REST の設計を理解すると、その制約（過剰取得・往復回数）への対案として GraphQL の発想が際立つ。Learning GraphQL はクライアント主導のクエリとスキーマ駆動の型システムを学ばせ、REST との使い分けの判断軸を与える。
理由: テキストベースの REST を押さえたうえで、サービス間通信の高効率な選択肢として gRPC へ視野を広げる。gRPC Up and Running は Protocol Buffers による契約定義と双方向ストリーミングを学ばせ、内部マイクロサービス通信の現実解を示す。
理由: OpenAPI で記述する設計駆動の REST を経験したら、同じ「スキーマ先行」の発想を別の形で実現する GraphQL を比較する。型付きスキーマを軸に API を設計する共通点と、問い合わせモデルの違いが理解を深める。
理由: OpenAPI による契約設計に慣れたら、より厳密でバイナリ効率の高い契約として Protocol Buffers を用いる gRPC へ進む。スキーマから型とスタブを生成する開発体験を比較することで、契約駆動開発の幅が見えてくる。
理由: Spring でひと通りアプリを組めるようになると、フレームワークに引きずられた設計（DB やフレームワーク中心）の限界に気づく。クリーンアーキテクチャはビジネスルールをフレームワークから独立させる依存性のルールを与え、長期的に変更に強い構造を選べるようにする。
理由: システム内部の境界を設計できるようになったら、その境界をプロセス＝サービスへ分割すべきかという次の判断へ進む。Monolith to Microservices は「まずモノリスから」という現実的な指針のもと、分割の動機・進め方・落とし穴を体系立てる。
理由: API の設計ができるようになったら、その API を「誰がどの権限で叩けるか」を制御する認証・認可の層が要る。OpenID Connect は OAuth 2.0 を土台に本人確認を標準化した仕組みで、トークンベースのアクセス制御を API に組み込む定石を与える。
理由: Spring でアプリの骨格を組めるようになったら、実務で必須となる認証・認可を仕組みとして載せる。OpenID Connect の流れ（認可コード・トークン・ID トークン）を理解しておくと、Spring Security の設定が「何のための設定か」として腑に落ちる。
理由: Spring でデータベースを扱うようになると、ORM の裏で実際に走る SQL とテーブル設計の良し悪しが性能や保守性を左右する。本書は「やりがちな失敗（アンチパターン）」を切り口に、リレーショナル設計の原則を実務目線で身につけさせる。
理由: アーキテクチャ上はデータベースを「詳細」として外側に置くが、その詳細であるリレーショナル設計を疎かにすると現場で破綻する。アンチパターンを通じてスキーマ設計の勘所を押さえ、抽象の理想と実装の現実を両立させる。
理由: Go の基本的なシステムプログラミングができるようになったら、Go 最大の武器である並行処理を深く掘り下げる。Concurrency in Go は goroutine とチャネルを使った「メモリ共有ではなく通信で協調する」設計を体系立て、安全な並行プログラムの組み立て方を与える。
理由: 単一プロセス内の並行処理を理解したら、複数プロセス＝サービス間で非同期に協調する世界へ広げる。Microservices Patterns はメッセージング・Saga・イベント駆動といった分散システムの協調パターンを与え、並行性の発想をネットワーク越しに展開する。
理由: モノリスを分割すべきかの判断ができたら、実際に分割した先で必要になる実装パターンの引き出しを揃える。Microservices Patterns はサービス分割・データ管理・通信・デプロイの定石をカタログ化し、「どう分けるか」から「どう作るか」へ橋渡しする。
理由: 境界と依存の原則を一つのプロセス内で設計できたら、その原則を分散システムへスケールさせる。Microservices Patterns は各サービスの内部設計（アーキテクチャ）を保ちつつ、サービス間の通信・整合性・障害をどう設計するかの語彙を与える。
理由: 分散システムを実装する力がついたら、それが「壊れたときにどう振る舞うか」を設計する視点が不可欠になる。Release It! はサーキットブレーカーやバルクヘッドといった安定性パターンを与え、障害が連鎖しないシステムを設計させる。
理由: 並行処理を書けるようになると、タイムアウト・リトライ・リソース枯渇といった「並行ゆえの障害」に直面する。Release It! はこうした失敗を前提に置く安定性パターンを与え、並行コードを本番で生き残らせる設計を教える。
理由: 単一のリレーショナルデータベースの設計を理解したら、複数のデータストアが絡む大規模システムの全体像へ視野を広げる。Designing Data-Intensive Applications は複製・分割・整合性・障害といったデータシステムの根本原理を、技術の流行に流されず体系化する。
理由: マイクロサービスの実装パターンを学ぶと、サービス間でデータをどう一貫させるかという難所に必ず突き当たる。Designing Data-Intensive Applications は分散データの整合性・複製・トランザクションの理論を与え、パターンの「なぜ効くか」を裏付ける。
理由: データシステムの理論を押さえたら、それが実際のサービスでどう適用されているかの実例で血肉化する。「ドラゴンクエストXを支える技術」は大規模オンラインゲームの運用・スケール・障害対応を具体的に語り、抽象的な原理に手触りを与える。
理由: 安定性パターンで「壊れにくいシステム」の設計原則を学んだら、それを長期運用で実践した事例から学ぶ。大規模オンラインゲームの継続運用は、理論上の安定性設計が現実の負荷と障害にどう晒されるかを示す生きた教材になる。
理由: 依存の向きを制御するアーキテクチャを学ぶと、そのテスタビリティの恩恵を最大化するテスト設計の原則が欲しくなる。単体テストの考え方/使い方は「良いテストとは何か」を定義し、アーキテクチャが生む疎結合をテストの価値に変換する。
理由: Spring でアプリを書けるようになったら、その振る舞いを保証する単体テストを「正しく」書く原則を学ぶ。テストの量だけでなく質――何を検証し何をモックすべきか――を理解することで、変更に強く壊れにくいテストスイートを育てられる。
理由: 単体テストの原則を身につけたら、サービス境界をまたぐ API のテスト戦略へ視野を広げる。Testing Web APIs はテストピラミッドの上位――統合・契約・E2E――をどう配分するかを示し、単体テストだけでは守れない API の信頼性を確保する。
理由: API を設計できるようになったら、その設計が「約束どおり」動き続けることを検証する手段が要る。Testing Web APIs は契約テストの考え方を与え、提供側と利用側のすれ違いを CI で検出できるようにする。
理由: サービスを分割すると、サービス間のインターフェースが変わるたびに連携が壊れるリスクが生まれる。Testing Web APIs は消費者駆動契約（CDC）を含む契約テスト戦略を与え、独立デプロイを安全に保つ検証の網を張る。
理由: 良いコードの感覚は、関数やクラスの内部だけでなく、外部に公開する API の設計にも地続きで効く。命名・一貫性・予測可能性というクリーンコードの原則を、URI やレスポンス設計という API の「公開された名前」へ広げて考える。
理由: TCP/IP の基礎を踏まえたうえで、HTTP・URI・HTML といった Web を成り立たせる技術を体系的に学び直す。「Web を支える技術」はプロトコルからアーキテクチャまでを一本の筋で説明し、REST 設計へ進む前の共通言語を整える。
理由: Web の基盤技術を一通り押さえたら、それを使って「良い API」をどう設計するかという実践へ進む。Web API The Good Parts は HTTP の意味論に忠実な URI 設計・エラー表現・バージョニングの定石を与え、原理を設計判断に変換する。
理由: Web の基盤を理解したら、API を設計プロセスとして体系立てる視点へ進む。The Design of Web APIs はユーザー視点の API デザインと OpenAPI による記述を結びつけ、思いつきでなく方法論として API を設計する道筋を示す。
理由: マイクロサービスで「自律した部品を協調させる」設計を学ぶと、その発想は複数の AI エージェントを協調させるマルチエージェント設計に通じる。Practical AI Agent Development は、サービス分割で培った疎結合・通信・責務分担の感覚を AI システムへ応用する入口になる。
理由: 大規模データシステムの整合性・信頼性・スケールの理論を押さえると、それが AI エージェントを実運用に載せる際の土台だと分かる。Practical AI Agent Development は、データ集約システムで学んだ堅牢性の原理を、エージェントの状態管理やツール連携の設計へ橋渡しする。
理由: テスト設計の原則はフロントエンドにも通じる。テストピラミッドを土台に、UI は少数の E2E で要を押さえ、ロジックは単体で厚く守る——層を跨いでも判断基準は同じ。
次に探索する
依存関係でつながる分野