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.
RECOGNIZE Patterns
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.
ENFORCE Using Patterns
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.
Speaking of "Gut Feeling"...
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.
It's Your (Personal) Preference
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!
Awesome course! It really opened my eyes to the design patterns used in Laravel. Now to dig in to the more complex patterns I need more experience with. Thank you!
Thanks a lot! It's very good in addition to gurufactoring book, as real-world examples tour with comments.
One thing I’m missing is the DTO (Data Transfer Object) pattern. Just like the Repository pattern, which isn’t as popular or widely used these days, DTOs also seem less essential in modern development. However, I’d still like to see some practical examples of how the DTO pattern can be applied, especially in Laravel.
The DTO itself is not quite a pattern. It's more of a way to transfer data between methods. So this wouldn't fit into the design pattern workflow at all. But we do have an older tutorial on DTOs here: //post/value-objects-and-data-transfer-objects-in-laravel
As for repositories - we are strong believers that Repository pattern is not worth pursuing in Laravel. There is more negatives in using it with Laravel than there is benefits. Especially if you are just starting and heard the phrase "repositories are required in modern applications".
You're absolutely right—DTOs are more about structuring data transfer rather than being a design pattern. Thanks for sharing the tutorial! As for repositories, I completely agree. In Laravel, they often lead to unnecessary code duplication since Eloquent already provides a great abstraction. In most cases, adding a repository layer just adds complexity without real benefits.