TL;DR;
Building good designs is a continuous journey that requires practice, experimentation and reflection. Look at diagram below. Google the keywords. Practice one thing at a time. Understand patterns and guidelines before using them. Engage your brain when designing and coding to relate it back to desirable properties of good system design.
Our journey of awareness of what makes good software
And the answer to "what makes a system design good?" is .. drum roll ... it depends.
"There is no silver bullet". Even then, there is no perfect design.
Theoritcally maybe, but the cost of perfection it so high. So we have a vast body of knowledge that is continuously evolving on this topic in our industry.
Whether you learnt a lot of this stuff formally in acamedia or not - it's something that no one ever masters, and it is something we should strive to continuouly reflect upon.
Get to the point!
Disclaimer: this is a picture of my personal journey which I have been on and will be always growing my entire career. It is not a comprehensive daigram that will stand the test of time, or be effective for everyone. It leans towards an OOP background.
Rather than regurgitating the meaning of each topic when there are so blogs and articles covering all these design-related topics and more, I will let you google.
A few points from the diagram:
- Don't aimlessly use design patterns without understanding their intention
- Don't aimlessly use design principles without understand why they are there to help us
- Avoid allowing specific technology dictate key parts of your architecture - or even at all (notice diagram is void of technology - we dont need to lock into sepcific technologies, and we should defer these decisions as late as possible)
- Do understand the costs and benefits of getting your architecture to acheive desirable properties of system design
Where to start the journey
I would recommend starting at SOLID. Read around the design topics that underly the principles to gain deeper understanding of why they are their to help us, then work your way up to patterns (or just try your own patterns that satify the principles).
Experiment and reflect
Dont be afraid to experiment - how else do we learn!? Pick one thing at a time and see how yor codebases / systems can improve by applying them. Reflect on your experience and outcome.
Code wrangler: "It's not my job to do this stuff"
You have a senior / lead architect? It's not all their responsbility: it's everyone's. They are not the gatekeepers of design - these senior roles are just human and are on their journey too.