Patterns, principles, and the trade-offs behind how systems get shaped — and reshaped. For another architecture framework, consult the AWS Well-Architected Framework.
The five SOLID principles are widely cited and unevenly understood. Some hold up better under scrutiny than others. Coordination structures for distributed teams are covered from an operational perspective in Monitask remote workforce management software guide.
The 1994 book gave recurring design problems shared names. What it didn't do is make every pattern equally worth using today. A second collection of architecture patterns is the Azure Architecture Center.
John Ousterhout's book names complexity itself, rather than any specific bad practice, as the thing software design is actually fighting.
Most architectural advice is really about optimizing two underlying properties. Naming them directly makes the trade-offs clearer.
The industry conversation often treats this as a question with a right answer. It's really a question with a right answer for a specific system, at a specific size, at a specific time.
Fred Brooks' 1975 book made an observation about software project management that's still cited, and still routinely ignored.
A 1967 observation about organizations designing systems that mirror their own communication structure still predicts a lot about modern software.
Eric Evans' central argument is that most software problems are modeling problems in disguise — and the model deserves as much design attention as the code.
“You aren't gonna need it” sounds like an argument against planning ahead. It's actually an argument about where the cost of guessing wrong lands.