Book
Clean Architecture
Robert C. Martin
Summary
Robert C. Martin follows Clean Code and The Clean Coder with a book aimed one level up: not how a function or class should look, but how a whole system's boundaries and dependencies should be arranged. It works through SOLID, then builds toward the Clean Architecture pattern itself, concentric circles with business rules at the center and frameworks, databases, and the web pushed to outer, replaceable layers, a design that shares its DNA with Alistair Cockburn's Hexagonal Architecture. Along the way it covers component cohesion and coupling, "screaming architecture," and how strongly a boundary needs to be drawn, from a plain namespace split up to full microservices. The argument running through it is that these decisions, not the framework you pick, determine how expensive the system is to change five years in.
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
- Developers who've applied SOLID at the class level and now need to decide where a system's boundaries actually go
- Architects deciding how strongly to separate a module, from a namespace split up to a standalone service, before committing to microservices
- Teams revisiting a codebase where the framework and the database have quietly become the architecture
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
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.
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
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
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.