The series of books on the Architecture of Open Source Applications should be a mandatory reading in all CS grad courses.

As they say,

Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's successes.

The goal of this AOSA book series is to change this by asking authors of well-known open-source projects about how they structured their projects, why they did it that way and what they learned during the process.

I've learned a lot reading the books and I'm convinced you will as well. Reading ALL these "lessons learnt" really helps you to see architecture design with a different perspective.

To entice you to read the books in full, let me just give you 15 of the many wisdom pearls on software architecture you'll learn. Note that you can read the books for free online but you can also buy them in more convenient formats (royalties from these sales are donated to Amnesty International).

15 wisdom pearls on software architecture (in no particular order; these ones are all taken from the first book in the series):

1. The structure of a program [...] clearly is not designed up front. It is something that develops over time. James Crook
2. It's difficult to think clearly about program architecture after code debugging begins. Margo Seltzer and Keith Bostic
3. Two copies of any specific functionality in your code guarantees that one of them is incorrectly implemented. Margo Seltzer and Keith Bostic
4. Developers are happier and more productive when using the tools they are most familiar with. By allowing developers to use their preferred tools, projects can take the best advantage of their most important resource: the developer. Bill Hoffman and Kenneth Martin
5. You don't have to maintain backward compatibility with something that users don't have access to. Bill Hoffman and Kenneth Martin
6. The choice of architecture seems to canalize or direct development towards a particular set of features. C. Titus Brown and Rosangela Canino-koning
7. API IS forever. A stable API is a contract between the client or API consumer and the provider. Kim Moir
8. It is hardly ever worth it to spend a lot of time designing an application to be 100% future-proof. it is quite likely that a painstaking design phase will introduce complexities that you will never need because the scenarios you prepared for never happen. Emil Ivov
9. A Package that enters the standard library has one foot in the grave. Tarek Ziadé
10. Design principle. Accept that one programmer is finite. Eric Allman.
11. Most features in the system were designed as direct response to user feedback. However,[...] being responsive to users does not necessarily mean doing exactly what they ask for. Juliana Freire, David Koop, Emanuele Santos, Carlos Scheidegger, Claudio Silva, and Huy T. Vo
12. The near-term future focuses more on managing the growth of the community as well as the software. Berk Geveci and Will Schroeder
13. Scalability has very little to do with low-level performance but instead is a product of overall design. Chris Davis
14. You can learn much more from closely studying actual failures than from theorizing about superior strategies. Chris Davis.
15. Keeping replicas of your data on multiple machines consistent with one-another is hard. Adam Marcus