Domain
Backend Development
A learning path to systematically build implementation skill and design principles for backend development — from API design and server-side architecture to authentication, async processing, distributed systems, and performance optimization.
The Terrain of This Field
The terrain of backend development can be read as a single continent you climb from the coastal lowlands to the inland highlands. The shoreline is the trailhead of "language and quality" — the foundation that lifts you from merely making code run toward code that is readable and easy to change.
At the mid-slopes the path forks into two ridges. One is the ridge of "communication and interfaces," rising from TCP/IP through web APIs and authentication. The other is the ridge of "design," from class-level design patterns up to system-wide dependency design (clean architecture). The two can be climbed independently, but they converge at the pass of frameworks.
Deeper inland rise the mountains of "scale, data, and stability" beyond a single server: the judgment of splitting a monolith into microservices, the patterns that implement it, designs that withstand failure, and the summit of data-intensive design. The key to surveying this field is that the scale of concerns connects continuously — from a single line of code to large-scale operations.
Follow the arrows to read in order / solid = required, dashed = recommended
Share this map
Grouping
Difficulty
Difficulty
Dependencies
Computing layout...
Books in this domain
28 books
スッキリわかる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
Dependencies
Reason: Once you can write basic Java syntax, the next step is to raise your sights from merely working code to code that is readable and easy to change. Clean Code provides principles for naming, function decomposition, and comments—building the sense of quality that is hard to acquire on your own.
Reason: Once you can write clean functions and classes, it's time to learn design patterns—named solutions to recurring design problems—through Java code. This book lets you experience the 23 GoF patterns in Java implementations, building a vocabulary of reusable designs and the ability to compose relationships between classes with clear intent.
Reason: With Java fundamentals in place, you move on to the Spring Framework, the de facto standard for server-side development in practice. Concepts like DI, AOP, and MVC assume a grasp of plain Java, so you layer the framework's abstractions onto your language understanding step by step.
Sources
Reason: Once you can wield class-level patterns, you broaden your view to how dependencies and boundaries are designed across the whole system. Clean Architecture offers the Dependency Rule—pushing details outward and keeping business rules at the center.
Reason: Once you understand how TCP/IP and HTTP work, the design decisions of REST APIs built on top of them make sense down to the 'why.' Web API: The Good Parts offers practical guidance on URIs, methods, and status codes grounded in HTTP semantics.
Reason: After grasping how networks work, you descend to the OS layer that actually handles that communication. Linux system programming introduces the APIs—sockets, processes, file descriptors—on which servers run, bridging protocol and implementation.
Reason: This is the stage where protocol understanding connects to building a server that actually runs. System programming in Go shows how to write network services in a language strong at concurrency, turning TCP/IP knowledge into working code.
Reason: Knowing the OS-level mechanisms for processes, I/O, and memory lets you see what Spring abstracts away under the hood. This low-level understanding keeps the framework from being a black box and pays off when diagnosing performance issues and failures.
Reason: Having once felt the effort of writing a server with raw system programming, you grasp viscerally what a framework like Spring takes off your hands. Low-level experience gives you perspective to weigh a framework's convenience against its constraints.
Sources
Reason: Once you've grasped the basics of REST design, you advance to describing and sharing an API as a 'contract.' The Design of Web APIs presents a spec-driven design process with OpenAPI, giving you a repeatable way to build consistent APIs across a team.
Reason: Understanding REST design throws GraphQL's ideas into relief as an answer to REST's constraints—over-fetching and round trips. Learning GraphQL teaches client-driven queries and a schema-driven type system, giving you criteria for choosing between the two.
Sources
Reason: With text-based REST in hand, you broaden your view to gRPC as a high-efficiency option for service-to-service communication. gRPC: Up and Running teaches contract definition with Protocol Buffers and bidirectional streaming, presenting a practical answer for internal microservice communication.
Reason: Having experienced design-driven REST described with OpenAPI, you compare GraphQL, which realizes the same 'schema-first' idea in a different shape. The shared emphasis on designing APIs around a typed schema—and the difference in query models—deepens your understanding.
Sources
Reason: Comfortable with contract design via OpenAPI, you move to gRPC, which uses Protocol Buffers as a stricter, binary-efficient contract. Comparing the experience of generating types and stubs from a schema reveals the breadth of contract-driven development.
Reason: Once you can build applications with Spring, you start to feel the limits of framework-driven design centered on the database or the framework. Clean Architecture provides the Dependency Rule that keeps business rules independent of the framework, letting you choose a structure resilient to change over the long term.
Reason: Once you can design boundaries inside a system, you face the next decision: whether to split those boundaries into separate processes—services. Monolith to Microservices, guided by the pragmatic 'monolith first' principle, systematizes the motivations, methods, and pitfalls of decomposition.
Reason: Once you can design an API, you need an authentication and authorization layer that controls who may call it and with what privileges. OpenID Connect standardizes identity verification on top of OAuth 2.0, providing the established way to build token-based access control into an API.
Reason: Once you can assemble an application's skeleton with Spring, you add the authentication and authorization that production demands. Understanding the OpenID Connect flow—authorization codes, tokens, ID tokens—makes Spring Security configuration click as 'configuration for a purpose.'
Reason: Once you handle databases with Spring, the quality of the SQL and table design running behind the ORM starts to govern performance and maintainability. This book teaches the principles of relational design from a practitioner's angle, framed around the antipatterns people commonly fall into.
Sources
Reason: Architecturally, the database sits on the outside as a 'detail,' but neglecting that detail—relational design—breaks down in practice. Learning the antipatterns sharpens your instincts for schema design, reconciling the ideal of abstraction with the reality of implementation.
Sources
Reason: Once you can do basic system programming in Go, you dig deep into concurrency—Go's greatest strength. Concurrency in Go systematizes the design of coordinating 'by communicating rather than sharing memory' using goroutines and channels, teaching how to build safe concurrent programs.
Reason: Having understood concurrency within a single process, you extend to a world where multiple processes—services—coordinate asynchronously. Microservices Patterns provides coordination patterns for distributed systems—messaging, sagas, event-driven design—extending the idea of concurrency across the network.
Reason: Once you can decide whether to split a monolith, you stock up on the implementation patterns needed after the split. Microservices Patterns catalogs the established practices for service decomposition, data management, communication, and deployment, bridging from 'how to divide' to 'how to build.'
Reason: Once you can design boundaries and dependencies within a single process, you scale those principles to distributed systems. Microservices Patterns gives you the vocabulary for designing inter-service communication, consistency, and failure handling while preserving each service's internal architecture.
Reason: Once you can implement distributed systems, designing 'how they behave when they break' becomes essential. Release It! provides stability patterns like circuit breakers and bulkheads, teaching you to design systems where failures don't cascade.
Reason: Once you can write concurrent code, you face 'concurrency-born' failures—timeouts, retries, resource exhaustion. Release It! provides stability patterns that assume such failures, teaching designs that let concurrent code survive in production.
Reason: Having understood the design of a single relational database, you broaden your view to the big picture of large-scale systems involving multiple data stores. Designing Data-Intensive Applications systematizes the fundamentals of data systems—replication, partitioning, consistency, faults—without being swayed by passing trends.
Reason: Learning microservice implementation patterns, you inevitably hit the hard problem of keeping data consistent across services. Designing Data-Intensive Applications supplies the theory of distributed-data consistency, replication, and transactions, underpinning why those patterns work.
Reason: Having grasped the theory of data systems, you flesh it out with a concrete example of how it's applied in a real service. 'The Technology Behind Dragon Quest X' concretely describes the operation, scaling, and incident response of a large-scale online game, giving abstract principles a tangible feel.
Sources
Reason: After learning the design principles of robust systems through stability patterns, you learn from a case that practiced them in long-term operation. The continuous operation of a large-scale online game is a living lesson in how theoretical stability design is tested by real-world load and failures.
Sources
Reason: Learning an architecture that controls the direction of dependencies makes you want testing principles that maximize the resulting testability. Unit Testing: Principles, Practices, and Patterns defines what a good test is, converting the loose coupling your architecture enables into testing value.
Sources
Reason: Once you can write applications with Spring, you learn the principles for writing unit tests that guarantee their behavior correctly. Understanding not just the quantity of tests but their quality—what to verify and what to mock—lets you grow a test suite that is resilient to change and not brittle.
Reason: Having mastered unit testing principles, you broaden your view to a testing strategy for APIs that cross service boundaries. Testing Web APIs shows how to balance the upper layers of the test pyramid—integration, contract, end-to-end—securing the API reliability that unit tests alone can't protect.
Reason: Once you can design an API, you need a way to verify that the design keeps working as promised. Testing Web APIs introduces contract testing, letting you catch mismatches between provider and consumer in CI.
Reason: Splitting into services creates the risk that integrations break whenever an inter-service interface changes. Testing Web APIs provides a contract-testing strategy including consumer-driven contracts (CDC), weaving a verification net that keeps independent deployment safe.
Reason: A sense for good code carries over from the inside of functions and classes to the design of the APIs you expose. The Clean Code principles of naming, consistency, and predictability extend naturally to URIs and response design—the 'public names' of an API.
Reason: Building on TCP/IP fundamentals, you systematically revisit the technologies that make the Web work—HTTP, URIs, HTML. This consolidates a shared vocabulary, explaining everything from protocols to architecture in one thread before moving on to REST design.
Reason: Once you have the Web's foundational technologies down, you move to the practice of designing 'good APIs' with them. Web API: The Good Parts offers established patterns for URI design, error representation, and versioning faithful to HTTP semantics, turning principles into design decisions.
Reason: With the Web's foundations understood, you advance to viewing API creation as a systematic design process. The Design of Web APIs connects user-centered API design with description via OpenAPI, showing how to design APIs as a methodology rather than by improvisation.
Reason: Learning to design 'autonomous parts that coordinate' with microservices, the idea carries over to multi-agent design that coordinates several AI agents. Practical AI Agent Development becomes an entry point for applying the sense of loose coupling, communication, and responsibility division cultivated in service decomposition to AI systems.
Reason: Having grasped the theory of consistency, reliability, and scale in large-scale data systems, you see it as the foundation for putting AI agents into production. Practical AI Agent Development bridges the robustness principles learned in data-intensive systems to designing agent state management and tool integration.
Sources
Reason: The principles of test design carry over to the frontend. Building on the test pyramid, you cover the essentials of the UI with a few end-to-end tests and protect logic densely with unit tests—the criteria stay the same across layers.
Explore next
Connected fields
Domain
Frontend Development
A systematic learning path for frontend development — from JavaScript/TypeScript to React/Vue, performance optimization, and accessibility, covering component design and architecture.
Domain
Software Design
A systematic learning path for software design — from clean code to architecture, testing, and quality culture. Covers code quality, TDD, DDD, distributed system design, and DevOps/quality organization.