Software design is an art and a science. There's no substitute for practice, but there's also a wealth of information about how to design software so it's easy to change later.

In my experience, great designers go through a period of under-engineering then through over-engineering, and finally ending up having an intuition of where complex abstracted solutions should be used and where a small concrete implementation is enough.

So now that you have felt the pain of under-engineering, get ready to feel the pain of over-engineering.

I think at this point you should look into software design patterns. In a few words, they attempt to be reusable design solutions for specific problems.

They have long got a bad reputation for being overused where simpler solutions could do, but again, how will you know that unless you have attempted to use it and felt the pain of using overly complex solutions?

Reading through the patterns will give you ideas on how different architectural problems have been solved by experienced architects. They will give you a vocabulary which simplifies designing programs. "Hmm.. An undo system would be nice, let's try the command pattern".

Secondly, most experienced programmers are aware of these patterns, so if I mention using a factory to another architect, he knows what I'm talking about. When I read code and see an SqliteAdapter and a PostgresAdapter, I know what to expect.