Status Updates From Fundamentals of Software Ar...

Chapter 25 is the most interesting and I enjoyed it a lot.

At the end of the book, the author emphasized that all software architecture is a trade-off, also any architecture decision are not binary and fall into a spectrum of trade-offs.

Overall the last few chapters are also barely readable.

The last part of the book is barely readable. The problem is that the author has placed the software architect outside of the developer team, and then spent Chapter 21, 22, 23, 24 to describe how they can work together. From my work expereice, these engineers are from the same team and they usually work together.

I found the these chapter hard to follow.

Part 2 is not very informative, except chapter 15.

Chapter 9 barely scratched the surface of the distributed system. Recently I've read Database Internals's Chapter 8, which done a much better job to describe all problems in less words.

Then the authors started to list all possible architectures. A lot of very shallow discussions, and I only learned a few interesting bit in Chapter 15.

The first part of the book was hard to follow. It is because the the authors spent a lot of time to explain what's a design and architecture, and the reader can be easily lost in the terminology introduced by the book, name a few examples

1. architectural quanta
2. "fitness function"

I found the book scratching the surface on a lot of aspects, and giving very basic example (ordering system, which is too shallow)

The first part of the book was hard to follow. It is because the the authors spent a lot of time to explain what's a design and architecture, and the reader can be easily lost in the terminology introduced by the book, name a few examples

1. architectural quanta
2. "fitness function"

I found the book scratching the surface on a lot of aspects, and giving very basic example (ordering system, which is too shallow)