I'm not a big fan of learning without an actual application to which it's applied.

Books on Modeling and Design are all well and good, but all of those suggestions need to be placed in the context of an application.

I have seen my share of "horrible" data models that work fine for the application. While there's a purity in having a "good design", the simple truth is that not everything needs a "good design". Or, better said, a "good design" for one application may be completely different than one for another.

Many simple applications perform fine with "stupid", "dumb", "bad" designs.

A lot of learning happens from doing the wrong thing.

To paraphrase Thomas Edison, "Progress, I've made lots of progress. I know a thousand things that don't work."

A lot of things are easier to learn when they're being applied in the "real world", and then judged against that metric of whether or not it's working or not vs simply holding it up to something read in a book, but unapplied.

The benefit of "good design" is that it works well with the "Code has Momentum" meme, specifically that a bad design, once entrenched, is difficult to refactor or remove and replace with a good design, so you want to start with a good design up front.

That said, as a corollary, especially if you follow blindly many books on modeling and architecture, you end up with simple applications that are terrible over engineered. With a lot of unnecessary code for circumstances that simply do not, and will not, exist in the application.

The game is finding the balance between "the perfect" solution, and the "workable solution".

So, read all the books you like, but also apply it to something of value to you, and then fix your errors as you grow. Not everyone should start at ground zero, you want to "stand on the shoulder of giants", but it's important to understand, also, the paths the giants took in the first place to better appreciate why, and in what situations, they advocate their choices.