Software Architecture Patterns [pdf]
oreilly.com
oreilly.com
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.
I've heard "the job of architects is to add abstractions to a design; the job of developers is to remove them"... possibly in reference to this article:
The most complex design tool outside of an IDE I've seen these guys use is plaintext and simple diagrams. They grok the thing that is being built in their heads from the CPU caches to the end-user abstraction.
The most horrible architects I've observed deliver UML:s, search for the most complex technical thing their mind can think of to solve a problem and then after saving the UML to disk think their job is "done" and hand-wave through the rest of the development pointing to the UML boxes.
The mediocre architects are a mix of these two.
An architect who is not participating in hands-on coding is a serious red-flag about the quality of the development organization in most instances to me. I'm sure there are counter-examples :)
Thanks for the this. This paragraphs sums up perfectly what I strive for in my day to day work. It's clear and concise.
So what would make design patterns more like real (physical) engineering? My best guess would be a formalization of the design contracts that they imply exist between the components implementing them.
I think that agrees with the spirit of my original comment. To answer your specific question: I'm not sure. If a book about software architecture is going to look at two implementations - say, Audacity and Bash to take two examples from the first book - then it has to work very hard to find an architectural language that applies in common to both. If it does not, then all that has really been accomplished is to peel the onion on some interesting applications, and while that is valuable and makes for an enjoyable read, I don't feel like it gets us any closer to actually understanding what the "architecture" of a software implementation is. The word has to mean something more than "things we've done in the past."
If you do that, you can also get the book in ePub or Mobi format.
I had one of those "So THAT'S what he was trying to do" moments when I realized that the architecture of an Android API layer that a client was having trouble with was attempting to be a microservices architecture. Instead it bollixed up the way Cursor objects work by trying to pass them across an AIDL-based remote API.
I bet that's not the last time I see that misapplication of a pattern.
I think what could be great is to have a tool that allows you to "program" and analyze architectures. And then exercises to experiment with varieties of architectures.