In order to learn about Design Patterns, you could read the book by the Gang of Four. I find Martin Fowler's "Refactoring" a more engaging introduction to design patterns:
The "Design Patterns" is like a taxonomy of patterns. It describes something that is alive, but in doing so, kinda kills it.
In "Refactoring", each chapter looks at a set of related patterns, explaining
How do you decide whether to use pattern A or B?
When the environmental conditions change: how to move from A to B, or from B to A?
This taught me two things:
The important thing about design patterns is to know when to apply one (and when not to)
You are allowed to change your mind!
This insight now affects many design decisions that I make. Say we're in point A, and we want to implement a new feature that requires either design B or design C. B and C might be patterns described in a book, or just something we made up ourselves.
Often the problem is guessing which solution will be more effective, more efficient, or easier to change when we need to add the next feature - a year or two from now. We can stand here discussing the pros and cons all day, but at the end of the day, we don't have a crystal ball and we'll still need to make a decision. Sometimes we can agree on a slight imbalance, so we pick one solution over the other together.
Sometimes we agree that we just don't know. Now I suggest to ask: So what if we do find out that the decision was bad?
Estimate the time it takes to drive from A through B to C, and from A through C to B, and compare. Very often there is a huge difference: Often the initial change to B is so cheap, and C is so expensive, that the detour is hardly noticeable if you really need to go to C. Maybe B is actually a step on the way to C that you have to do anyway.
In that case, if B was good enough, you've saved big time. If it wasn't, you've lost only a little. Turns out I don't need to be sure I'm right - I just need to be sure I'm not too wrong.