When creating a new project and blazing that trail there is this fear that lingers over our shoulder.
"What if I make a horrible engineering mistake?"
Here is the sad fact. You will. And more importantly, you need to make mistakes. This is probably one of the only areas that TDD makes a difference. With TDD (Test Driven Development) your actually making a journal of what your thought process was. You can see where you went wrong in your vision. If you don't do this you can end up in a situation where your just drifting from one mindset to the next and the code just doesn't mesh. In order to have the cleanest most functional and stable code you must completely refactor the old to the new possible solution. A series of unit test gives you a clear overview of what needs to be removed or changed. Of course good old fashion comments should also be used liberally in the design process. When you fail to completely refactor your code it increases the multiplier on code complexity. When you look at the code a year later each failed refactoring will cloud your understanding of the code and what you were trying to accomplish.
The other thing that we tend to do when designing a new project is over extract worthless abstraction layers. While abstraction layers can be helpful when EVERY interaction can be done through the abstraction layer. A majority of the time we will just bake a single functionality into the layer. While puritan OOP academia will tell you this is necessary to maintain a pure object oriented design. This design is not easier to follow for human or machine. The only winner is the badge you can pin on your chest for following the text book object oriented pattern. Even interfaces, when using base classes and extending them you should make sure that the interface your sharing warrants doing this. But even outside of academia nonsensical programming there is a natural drive for the engineer to try to simplify a process. But this is how you end up with a slew of weird garbage abstraction layers. Before adding a layer really think, would it be better if all my application accesses this functionality though my class instead of the originating class? If the answer is no than it would be probably better and easier to test if you make this a function a series of functions. If the language your using has modules than use a module to create a namespace to organize your functions instead of a class.
As far as design patterns go. I tend to follow MVC. But I do this when I evaluate a complicated function that needs to be reduced in complexity. I use MVC to help find the points in the code where it can be split out. But strict MVC developing is as much garbage as strict OOP. You win an imaginary badge that you can pretend to pin to your chest with the most wonky hard to read code. Strict MVC ends up over abstracting as much (sometimes worst) than puritan OOP.
So in my philosophy you use common sense and try to follow basic principles and remain focus on can I reduce functions and methods to a single task or functionality. An example break down is a function/method that reads a file. A function/method to do data transformations. A function/method that calls an event or notifies of new data. The tendency is to want to make mega function that does everything. First of all mega functions are a pain to unit test. But when you need to make, lets say, an extra data transformer. Now you might be tempted to copy-paste the previous mega function to make a new mega function with the transformation changes. Now if you try to refactor your code you have a CRAP TON of code breaking changes to make.
So really focus on trying to make every function has a single purpose limited in scope. Use MVC to focus and gain a perspective of purpose. Use OOP when there is a tight pattern in your code where you can reduce code and won't involve inheriting three or more interfaces. Embrace your design mistakes, learn from them, improve them.