I think the best place to start is this book:
https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
This book is worth reading twice.
One thing you will notice with these OO authors especially is that it might come across like they treat their ideas as a recipe to success. Don't think of it that way. Try to see the transendental ideas behind the concepts. The book above does get around to this at later chapters (explaining SOLID outside the OO sandbox), but just think about it this way: the main idea that this book is trying to convey is that of separation of concerns. It gives a solid framework for how to think about separation of concerns and introduces the invaluable concept of domain logic, which is so so so important in software design.
It also introduces the extremely useful concept of dependency inversion which helps you think about which
modules should depend on other modules. Again, the most explicit way to express depenency inversion is via
interfaces or traits, but this is not necessary. It's more important to try to understand how to design interfaces
and to understand why e.g. the interface provided by a data module should be tailored to a logic module (and never the other way around!) and why data should
ideally not expose any details of the particular database being used.
The next book I would recommend is this:
https://www.amazon.com/Philosophy-Software-Design-John-Ousterhout/dp/1732102201
This was written by the guy who invented Tcl and he's been in the industry for 40 years which is an awful lot of time. The important things: in particular, the way this book talks about cognitive complexity is really important to understand. It also has a very good treatment of information hiding. (What a piece of code should "hide" from the other code, and why.)
https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672
This is an extremely important book for how to avoid code rot. Later chapters are written like a dictionary of refactoring patterns, which is boring. Once again, the important ideas: why continious refactoring is necessary, why refeactoring and new features must be treated essentially as the same thing, how tests interact with refactoring (!!! more on this later, this is extremely important). The first two chapters are a must. The third chapter is also good. The fourth chapter is good too I think but I don't remember it.
The next one is highly problematic:
https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577
This book is extremely good and also extremely bad. The good, once again, are those ideas which are transcendental: it has a really good way of helping the reader understand how to decompose the world into concepts. The bad is that it's written like a cult Bible. It has "rules" and "recipes" and things like this that are useful to read once and understand the reasoning behind them, but in my opinion can be disregarded whenever it makes sense and if followed too strictly can lead to very long and annoying analysis sessions that don't produce the best design anyway. The idea of entities vs. value objects is a very good one though. It's full of good ideas, just don't take them too literally. This is a difficult book, maybe you should leave it for last.
Finally, one extremely important topic to understand, which ties closely to the refactoring book above, is that of writing autmated tests. Note that I avoid saying unit tests because nobody knows what a "unit" is. And "unit" is probably a bad idea to begin with, because testing a single function or a single module is rarely a good idea.
https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
Again, the book is written like a recipe. It doesn't matter if you test first, or test last, or refactor first, or refactor after. The important idea is: how do you get your tests to work for you rather than against you. The refactoring book above also touches on this. I think maybe you can skip this book. There is a good talk that summarizes a lot of the important ideas: