I think the best way to learn architecture is to try (and initially fail) to do some projects which make demands on your architecture abilities. I'd recommend writing some frameworks or engines (without worrying about fully completing and releasing them!). Where I learned the most about designing reusable systems was building a game engine, then actually building a game or two on it and seeing what was painful and what worked and taking notes, then building another engine based on my experience, and repeating. I built three engines by the end, and made maybe four or five (little) games off of them.
I never released any of them and none are useful for anything any longer. None probably reached more than 75% completeness. But by trying to build games on them I saw with such clarity things that worked and didn't, and I got deep practicing in thinking about more 'general' forms/concepts/structures. I wrote a framework for writing 3D model loaders after, and the lessons carried over. I was utterly lost when starting the first game engine; with the model loading framework I had to think deeply, but I new where I was going.
Here's something to consider. If you try to just start writing 'a game engine,' (or whatever engine/framework) that could mean about anything (from 1 day of work, to 20 years of work). But, if you consider some concrete ideas for particular games you'd like to make, think about what they have in common, and then try writing a piece of software that takes care of the common parts, you'll have constrained the problem to something workable with definite goals, and a way of testing your success after.
This is at the heart of any sort of 'abstraction' you develop: you want to code several things which have a bunch of overlapping aspects, so you write something that captures the common parts, and then arrive at the several things you actually need by instantiating your abstraction with different parameters (I mean that in a very general sense, not with specific reference to OOP, though it provides means of instantiating abstractions with various parameters too, of course).
I'd say being able to do the above effectively is the cornerstone of being able to do architecture well. A bunch of other stuff comes after, like knowing when to not create abstractions, and all sorts of knowledge about doing things well for systems in particular domains (e.g. architecture for an interactive 3d simulation vs. web apps have very different patterns that have surfaced as effective).
I never released any of them and none are useful for anything any longer. None probably reached more than 75% completeness. But by trying to build games on them I saw with such clarity things that worked and didn't, and I got deep practicing in thinking about more 'general' forms/concepts/structures. I wrote a framework for writing 3D model loaders after, and the lessons carried over. I was utterly lost when starting the first game engine; with the model loading framework I had to think deeply, but I new where I was going.
Here's something to consider. If you try to just start writing 'a game engine,' (or whatever engine/framework) that could mean about anything (from 1 day of work, to 20 years of work). But, if you consider some concrete ideas for particular games you'd like to make, think about what they have in common, and then try writing a piece of software that takes care of the common parts, you'll have constrained the problem to something workable with definite goals, and a way of testing your success after.
This is at the heart of any sort of 'abstraction' you develop: you want to code several things which have a bunch of overlapping aspects, so you write something that captures the common parts, and then arrive at the several things you actually need by instantiating your abstraction with different parameters (I mean that in a very general sense, not with specific reference to OOP, though it provides means of instantiating abstractions with various parameters too, of course).
I'd say being able to do the above effectively is the cornerstone of being able to do architecture well. A bunch of other stuff comes after, like knowing when to not create abstractions, and all sorts of knowledge about doing things well for systems in particular domains (e.g. architecture for an interactive 3d simulation vs. web apps have very different patterns that have surfaced as effective).