One of my goals in this course was to show you the options for which patterns you may use. I tried to limit them and show only the most practical ones, but maybe you're still confused about how to use all that information in your situation.
By showing different examples, I wanted you to notice the patterns. This is the most common thing you need to do in your daily development life.
You would often need to take someone else's code and add features, not breaking the pattern from the original author.
Another example would be a PR to an open-source package. Or, maybe you could submit a PR to Laravel. Without reusing the same patterns as the framework, your effort would likely be rejected.
Finally, noticing patterns helps to understand and navigate the code more quickly. Getting back to the analogy of traffic: after you visit a few foreign countries, it's much easier to drive around in a third or fourth different country because your brain notices the patterns in roads and signs.
The next "level" is to think about people who would work on that code after you're done with your task.
Would they be able to recognize patterns and continue maintaining the codebase in the same way?
So, you may want to introduce some more strict structure as patterns, if they weren't used previously.
And here's the million-dollar question: which pattern should be used when creating code from scratch? Service? Action? Facade?
My advice is this: when building such an architectural-level structure, try to reuse it right away. Try to mimic the behavior of the "next developer" who would try to use your pattern and class/interface structure. You will likely have a gut feeling about whether your chosen pattern is a good fit.
In the end, the choice of design pattern is your preference. Including the option of choosing no patterns. There's no one-size-fits-all solution. You may regret the choice in the future. Or, most likely, that choice will be criticized by other devs who would take over that codebase.
You learn to use design patterns only by trying them in practice. That's why senior developers usually have a "gut feeling" about whether the choice is good, based on previous decisions.
When answering dev questions, I often like to reply with "It's your personal preference" but that's not entirely true. Your preference should be based on the context of the project/team you're a part of.
The chosen patterns may be totally different depending on the team size, budget, deadlines, and other factors. However, I hope my course will give more context for future preferences.
Finally, as I said at the beginning of the course, I'm ready for discussions in the comments and improving the lessons based on your feedback.
And see you guys in other courses!