Here are some pointers:

"Large-Scale C++ Software Design"

https://www.amazon.com/Large-Scale-Software-Design-John-Lako...

Although oriented towards C++, many architecture tips apply to other languages as well.

John Lakos is in the process of writing updated versions of the book.

"Large-Scale C++ Volume I: Process and Architecture"

https://www.amazon.com/Large-Scale-Architecture-Addison-Wesl...

"Large-Scale C++ Volume II: Design and Implementation"

https://www.amazon.com/Large-Scale-Implementation-Addison-We...

Then going back into the old days, you have

"Software Engineering in Modula 2: An Object Oriented Approach"

https://www.amazon.de/-/en/Jill-Hewitt/dp/0333515188

"Data Structures and Program Design in Modula-2"

https://www.amazon.de/Larry-R-Nyhoff/dp/0023886218/ref=sr_1_...

"Code Complete: A Practical Handbook of Software Construction"

https://www.amazon.com/dp/0735619670/ref=sr_1_1

"AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis"

https://www.amazon.com/AntiPatterns-William-J-Brown/dp/04711...

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/Component-Software-Object-Oriented-Pr...

"Use Cases Combined With Booch/Omt/Uml: Process and Products"

https://www.amazon.com/Use-Cases-Combined-Booch-Omt/dp/01372...

Just some pointers to get you started.

The "Antipatterns" section of the site is the verbatim text of "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis" [1], which is one of my all-time favorite books, but doesn't seem to credit the original at all. Is this site ripping them off?

[1] https://www.amazon.com/AntiPatterns-Refactoring-Software-Arc...

"No list like this would be complete without a book about design patterns."

If this is true, then no such list is complete without the Antipatterns book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (http://www.amazon.com/AntiPatterns-Refactoring-Software-Arch...).

The thesis is that if good software, projects and teams are noted for using good patterns, then bad versions of any of the above will be marked by bad patterns, and one won't have the other. This can also be a lot more useful in practice, since we seldom get complete greenfields to play in, and therefore antipatterns with prescriptions to fix them more often match what we find in the real world.

I note there are a number of other antipatterns books; this was the original, and now seems to be back in print without needing any changes are updating.

One of the reasons really like and recommend the Antipatterns book (http://www.amazon.com/AntiPatterns-Refactoring-Software-Arch...) and approach is that it starts with the identification of a bad pattern (this author's complaints are at a higher level, though) and ends with recommendations on how to re-mediate it.

As you indicate, based on this article it's hard to see Mr. Rainey providing constructive help, and for that matter I wonder what he's trying to accomplish with this screed. I suppose that's consistent with it, the major takeaway is "don't get involved with this person or his firm!"

See my other comment on how anti-patterns are supremely useful when you're working in a brownfield (existing subpar codebase, project, etc.) and you need to recognize the problems and having suggestions about how to fix them is very helpful.

You can also try reading the anti-patterns book for an introduction to many of the most important ones, or rather books: http://www.amazon.com/s?index=blended&link_code=qs&f...

Although I can only vouch for the tremendous usefullness of the first: http://www.amazon.com/AntiPatterns-Refactoring-Software-Arch...

Hmmm, I think it went out of print but it's back.