The book consists of 7 parts, each of which, in turn, is made up of several chapters (from 5 to 10). Let’s briefly go through the sections.
Introduction
Well, here everything is usual and standard. What clean architecture is and why it’s needed. The information is presented in the form of various charts, such as employee growth over a certain period and their productivity (which, as you can guess, did not increase, because the point is that bad architecture can seriously kill and slow down a project).
Basics: Programming Paradigms
The section begins with a brief history of programming from the times of Alan Turing and the first languages. It describes structured programming, OOP, functional programming. A few words are said about testing. There are code examples — they are in C.
Design Principles
Here, there is already a mention of a pattern, or rather the SOLID rule. Basically, that’s it. 5 separate chapters, each covering one principle.
Component Organization Principles
The section includes an analysis of the concept of a component. A component can also be understood as modules and other independent pieces of code. Topics such as component cohesion and coupling are also covered. Attention is given to abstractions, top-down and bottom-up design. The problems of cyclic component dependencies are raised.
Architecture
Here, things start to get more interesting and practical. Although the beginning of the section still leans more towards the purely theoretical, as it discusses the stages (phases) of software development. Also, right from the start, the author touches on such an important topic as separating code layers, which are then detailed in the following chapters of this section. One of the hardest things, according to the author, in separating code is defining boundaries (between components), which is hard to argue with. A couple of examples and real stories are described. The topic of monoliths is also considered. Finally, after listing many pitfalls, the author approaches the topic of clean architecture. In his view, clean architecture is a layered, onion-like structure that starts from business logic rules and ends with the last level in the form of I/O systems and various interfaces. The role and place of databases in such architecture and other patterns like controllers, models, and others in clean architecture are briefly discussed.
Details
This is exactly the title of one of the last sections. Here, more detailed attention is given to the role of databases in a project and web interfaces. It is said that a framework is just a tool and that one should not strictly stick to the recommended architecture of a particular framework. The book ends with an appendix describing what computers used to be like and how people had to work with them.
Conclusion
Let’s start with the advantages, or rather, just the features of this book. It is easy and quick to read, as there is little code, but on the contrary, there are diagrams and flowcharts. There are illustrations in each chapter in a suitable, unified style. Among the downsides — this book is more for beginner developers. Newbies should read it thoroughly, more experienced ones will rather skim through it (it won’t take much time), and for seasoned developers and software architects, the book is unlikely to seem useful.
