Book
Clean Architecture
Robert C. Martin
Summary
ビジネスロジックをフレームワークやDBから分離し、独立してテスト可能なシステム構造を構築するための 依存性逆転の原則に基づく普遍的設計原則を解説。
Editor's Note
For readers who've mastered quality at the function and class level and now want to design system-wide boundaries and dependency direction. Broad in scope, it offers design principles that apply at any scale — more philosophy than concrete code.
Target Readers
- アーキテクチャ設計に携わるエンジニア
- Clean Code既読の中級開発者
Tags
Colophon
- Publisher
- KADOKAWA
- ISBN
- 978-4048930659
- Published
- Jul 2018
- List price
- ¥3,520incl. taxMay differ from the actual selling price on Amazon
Get this book
* The link above is an advertisement via Amazon Associates.Related Books
Prerequisites
- Recommended
Java言語で学ぶデザインパターン入門
結城浩
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.
- Recommended
Spring徹底入門
株式会社NTTデータ
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.
- Recommended
Clean Code
Robert C. Martin
Reason: Once quality at the function and class level is second nature, the next step is to design the direction of dependencies and boundaries across the whole system. Clean Architecture provides the principle of pushing details outward and keeping business rules at the core.
- Related
オブジェクト指向における再利用のためのデザインパターン
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Reason: After acquiring a vocabulary of class- and object-level patterns, you widen your view to governing the direction of dependencies and boundaries across the whole system. Clean Architecture pushes details outward and keeps business rules at the center.
Next Books
- Recommended
Monolith to Microservices
Sam Newman
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.
- Recommended
マイクロサービスパターン
Microservices Patterns
Chris Richardson
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.
- Recommended
Unit Testing Principles, Practices, and Patterns
Vladimir Khorikov
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
- Recommended
Fundamentals of Software Architecture, 2nd Edition
Mark Richards, Neal Ford
Reason: After gaining an intuition for the ideal shape from Clean Architecture, you formalize architectural characteristics and trade-offs into a shared vocabulary. This book elevates design judgment from personal instinct to a discipline you can reason about.
- Recommended
Learning Domain-Driven Design
Vlad Khononov
Reason: Once you can control the direction of dependencies, the next question becomes where to draw the boundaries. Domain-Driven Design derives bounded contexts from the language of the business, giving architectural decomposition real meaning.
- Recommended
A Philosophy of Software Design, 2nd Edition
John Ousterhout
Reason: Once you have the principles of dependencies and boundaries, you descend to the universal question beneath them: how to contain complexity. Ousterhout systematizes complexity management through the lens of deep modules and information hiding.
- Recommended
チームトポロジー
Matthew Skelton, Manuel Pais
Reason: Once you can design technical boundaries, you widen your view to the fact that those boundaries and team structure shape each other—Conway's Law. Architecture is not only a code problem but an organizational one.
- Recommended
Building Microservices
Sam Newman
Reason: The principles of dependency direction and boundaries apply directly to designing service boundaries. You connect them to concrete decisions that map bounded responsibilities onto independently deployable units.
- Recommended
エンタープライズ アプリケーションアーキテクチャパターン
Patterns of Enterprise Application Architecture
Martin Fowler
Reason: Once you have the principles of layering and dependency direction, you advance to the source of the canonical patterns that implement them—Repository, Service Layer, Domain Model. Mapping principles to patterns deepens your design vocabulary.
- Related
失敗から学ぶRDBの正しい歩き方
曽根壮大
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