Does software architecture sound like a vague philosophical idea, disconnected from the practicalities of programming? Yes? This might be a good read.
I liked Clean Code and The Clean Coder by R. Martin, I felt tempted to read this other volume about software architecture. While I had been hesitating for some time, reading just enough software architecture by G. Fairbanks revamped my interest, and I took the (tiny) plunge. Besides, I got to try the Amazon Kindle for the first time, and I liked it!. The book still costs 15 EUR on Amazon though.
R. Martin details his “Clean Architecture” in six parts. After an introduction in Part I, he explains in Part II why the rules of software architecture are unlikely to change before he reiterates his SOLID principles in Part III. From there, he “zooms out” and discusses how these SOLID principles apply to larger software entities, namely components in Part IV and architecture in Part V. In Part VI, he lists details such as GUI, storage or frameworks that can hurt the architecture. The curious will find in Part VII a selection of war stories from Robert’s career that shaped this “clean architecture”.
Robert Cecil Martin is one of the louder voices in Software Engineering. He has authored books and magazine articles on programming, agile practices, and was one of the founders of the Agile manifesto.
As for the style, I found Robert’s voice peremptory, and I am not so much into war stories from the 60ies. Robert argues convincingly and mainly refers to relevant books and articles, but I don’t remember empirical about others using his clean architecture.
As for the substance, this is more technical than other books on software architecture. It is about classes, modules, components, releases, etc. I felt Part II and III add little if, like me, you already went through Clean Code and The Clean Coder. But I like the rest. The clean architecture departs from “testing from the very outset”, which ensures the user always has something to play with (see Growing-object oriented system guided by tests). Robert trades this against tests that better withstand changes over time, since they don’t hit volatile things like the UI or the storage, etc. It’s a tradeoff.
Eventually, I liked it and gave it 3 stars. I would recommend it to those that see software architecture as a pure (useless?) academic exercise. Robert’s clean architecture is one practical way to bridge the model-code gap, that is, to have an architecture that exists beyond whiteboards.