I agree with the "layered" and "event driven" problem. I would characterize them as concepts on orthogonal dimensions, and not things to be compared or contras

I agree with the "layered" and "event driven" problem. I would characterize them as concepts on orthogonal dimensions, and not things to be compared or contrasted (after skimming over those sections) But AOSA is a book of case studies, which is of enormous value. I don't see the problem there. The authors don't give you the unifying themes, because each chapter was written in isolation. You have to fill in the blanks. But really reading alone isn't enough. That book gives you a taste, but if you really want to understand an architecture, you have to make changes in the codebase. There's no book that can give you that information. And I feel like I know what software architecture is. It's about 1) how a piece of software is divided, and 2) the relationships between those parts. This book and I would say any other book about architecture can be described like this. Whether the architectures are good or described well is a different matter. That doesn't mean it's easy, or application-independent, or that every piece of software even has an architecture. But software architecture is quite well defined.