Software Architect's Handbook
By Joseph Ingeno (Packt, 2018)
This is another great book I highly recommend for software architects, but it needs to be read with correct expectations: it gives you breadth, not a lot of depth. It covers a lot, see its ToC, not in every details you may like, but in my case that was exactly its advantage - it gave me a better context for all various elements of architecture topics.
For instance, Domain Driven Design (DDD) is only few pages, without a lot of detailed information, merely listing the relevant terms of DDD with some short explanations, but refers to the most important book of DDD, Eric Evans' Domain-Driven Design: Tackling Complexity in the Heart of Software. Similarly for other chapters, you have references to the relevant books of that topic.
Other chapters are covered in much mode details, like Software Quality Attributes, Software Architecture Patterns, or Cross-Cutting Concerns. I liked how was explaining coupling and cohesion types, or Service-oriented architecture (SOA), to give just few examples, but in fact are much more sections like these.
But even more important, I liked how was explaining architecture design processes and architecture evaluation methods. Having clearly listed options like Attribute-driven design (ADD), Microsoft's technique for architecture and design, Architecture-centric design method (ACDM), Architecture development method (ADM) as used by TOGAF for the former, and Software architecture analysis method (SAAM), Architecture tradeoff analysis method (ATAM), Active design review (ADR), Active reviews of intermediate designs (ARID) for the latter, with their phases and steps helped me to put them in context.
Of course there are many other chapters it covers, like requirements elicitation techniques, architectural drivers, architecture patterns and design patterns, SOLID principles, performance and security considerations, architecture documentation (including a quick intro to UML), but also DevOps, even soft skills and leadership.
In almost 600 pages it covers a lot of ground for software architect role, even though is unlikely somebody would need all these details at once. The book is simply to read, in easy terms, pretty well organized, although not perfect. It has a lot of definitions and acronyms (all explained), good for reference when you need them. It doesn't have much code or document templates.
As an example of the down to earth advice you can get from this book, I liked a paragraph from legacy application chapter, I'd quote here:
Before making any changes, it is helpful to have the right attitude when approaching a legacy codebase. All too often, a software architect or developer will be highly critical of a legacy application before even fully understanding the codebase. You should have respect for the original development team because there may be reasons why things were done a certain way and you may not always be aware of all of the decisions that took place and the rationale behind them.