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.
medium-paced
informative medium-paced
informative slow-paced

Clean Code, scaled up.

If you liked what clean code did mostly on a file by file basis and want the same kind of advice for designing applications, this is the book for you.

Like clean code, it is a very easy read without a lot of surprises. If you've designed applications before, this is mostly an experience of "oh, I'm not alone in encountering this problem" and "that's a succinct way of expressing it".

An example is his definition of an architectural boundary: "A line in the architecture diagram that is only crossed by dependencies in one direction". Stable abstractions principle et. al. provide good tools to think about software design and architecture. There are also some (albeit very few) tips on how to apply the principles in practice.

My main takeaway is some added structure to my existing opinions around application design and additional mental models for reasoning about architecture.

The book is however a little abstract in sections, and the last chapter is more autobiography than architecture book. Uncle Bob is very well aware of how well known and respected he is and that is obvious from the tone of the book, which would benefit from a little more humbleness.

I still recommend this book as I think it builds a good foundation of software architecture knowledge, with clear, well defined terms, and is an easy read.

Very interessing but hard to read