3.5

A stellar book on the fundamentals of software design architecture.

While there is definitely a very valuable and clear thesis, there is a lot less wisdom per page here than in Clean Code. Still plenty of gems within though.

Якісне продовження "чистої" серії. Друга частина значно цікавіша за попередню, з ще більшою кількістю прикладів. Якщо "[b:Clean Code: A Handbook of Agile Software Craftsmanship|3735293|Clean Code A Handbook of Agile Software Craftsmanship|Robert C. Martin|https://i.gr-assets.com/images/S/compressed.photo.goodreads.com/books/1436202607l/3735293._SX50_.jpg|3779106]" - це основи, або IT-буквар як я говорив у відгуку, то "Clean Architecture" - це вже старша школа.

Автор грунтовно підказує як дизайнити код, який буде задовільяти не лише поточні вимоги, а і буде готовим до нових. Як каже Роберт Мартін, “Ціль архітектури - зменшити затрати на розширення”. Починається книга здалеку - з огляду парадигм програмування типу ООП, функціонального, структурного, тощо. Доповнюється вже більш приземленими поняттями і принципами. До речі, саме після прочитання цієї книги я зрозумів, що Single Responsibility насправді має на увазі не одну задачу яка рішається компонентом, а саме одну причину бути зміненим. Однією з найцінніших порад з книги я можу назвати “Відкладіть прийняття рішення, наскільки це можливо”, особливо коли це стосується технічних питань. Цього можна зокрема досягти використовуючи домен-центричні архітектури типу Hexagonal ([b:Get Your Hands Dirty on Clean Architecture: A hands-on guide to creating clean web applications with code examples in Java|52774354|Get Your Hands Dirty on Clean Architecture A hands-on guide to creating clean web applications with code examples in Java|Tom Hombergs|https://i.gr-assets.com/images/S/compressed.photo.goodreads.com/books/1570982771l/52774354._SX50_SY75_.jpg|73101998]) або Clean. Важливо пам’ятати що низькорівневі деталі мають залежати від високорівневих, як плагіни залежать від головного модуля, а не навпаки. Іншими словами це можна сказати що архітектура має бути use-case-driven, а не framework-driven. В кінці книги автор вводить термін "кричаща архітектура", описуючи добре спроектований проект, проект суть якого можна зрозуміти швидко оглянувши назви модулів і класів.

Це точно одна з книг, до якої ви будете повертатися знову і знову, доповнюючи її новим досвідом і реальностями індустрії. Варто мати її в своїй бібліотеці. Рекомендую

I feel like I'm on a different wavelength with Uncle Bob. The majority of my experience has been 1. in the cloud, 2. (micro-)service oriented and 3. using languages that don't require strict OOP. Also, a Software Architect needs to be able to talk about tradeoffs in design, which this book fails to do.

There were some sections that I kind of disagree with. In particular, dismissing the database as a architectural detail feels very optimistic and unrealistic (and almost armchair architect level of consideration, especially considering all of the tradeoff considerations required for distributed datastores). The insight provided by Clean Architecture (TM) was also presented to me early in my career (business logic isolation from data layer and APIs for clients, so that it's inter-operable between different types of clients and datastore), so I can't help but feel like it lacks depth (especially if a junior engineer was able to grasp it so easily).

The first half is a must read for anyone struggling with strategically improving a legacy codebase. I found the second half repetitive and less insightful but the first half was so good it warrants this book a permanent place on my shelf.

Although the covered topics could be perceived as "nothing new", one could argue that this exactly the point that the book is trying to make: rather than endlessly searching for a new revolutionary approaches, we should master following what we already know with unprecedented vigilance.

One of my favourite takeaways from the book is to make sure that the architectural choices made are also supported by automatic code analysis tools (so rather than just checking the style of the code, the approach on solving problems is also monitored as much as possible).

A very useful reference book that I will definitely come back to often. It makes me understand a lot more about why some architecture is good or bad.

## Description
[[Uncle Bob]] describes his learnings about what makes a good maintainable architecture and give examples from throughout his career up to the early 90'es.

## Strengths
Teaches and explains/shows the need for many best practices such as the [[SOLID]] principles and awareness of dependencies in time and code. It address monolith vs micro service and aims to extract generally useful approaches to how to build software regardless of technologies and their tradeoffs.
It also does a good job of communicating the dangers of making business logic too technology dependent.

## Concerns
Sometimes explain things in a slightly redundant way.
Most examples are from 3+ decades ago.

## Opinion
This is a book is approachable and teach good habits in how to think about structuring code.
It is a good introductory book for engraining good habits and it explains how the author learned the necessity of those habits himself throughout his growing career.

4/5 stars

It's a bit uneven - too much detail in some places, not enough in others. It also feels a bit padded, though maybe I felt that way because I was already familiar with some of the concepts.

For all its faults, there are some really important ideas here, which are generally well presented. I really liked the emphasis on principles over patterns.