That is an amazing content! I'm enjoying a lot your videos! And really liked the one about Service Pattern and DTOs! Keep up the great work buddy!

It is incredible, need more!

Thanks

very clean that code at the end.. thanks mr

That's awesome. Learned new things today before I sleep

* Long file does not necessarily mean bad, that is an all too common a fallacy. * I really disagree with removing fillable on the user model because it has the password hash, remember token, and possibly API tokens and the like. Yes, if everywhere is using validated you have some protection, but the model shouldn't trust that the controller is always doing the right thing every single time. Changes happen, and all devs (especially new ones) make mistakes. You should always error on the side of security. * Using an observer shortens the user model file, but doesn't really decrease LOC or improve readability -- just moves it. So, that is really 7 of one ceiling of half a baker's dozen of the other. That's personal preference, not "better code." * Agree with using enum for roles (or moving roles to database to make them more extensible). * Not sure I agree with moving the role functions to the role enum as it makes future possible changes that might happen harder, for instance at a later users may have more than one role and it would be easier to modify for that keeping the functions in the user model. Or for instance roles could become a model relationship in the future, and thus require those function move back to user. Keeping the function in the model instead of the enum makes better sense. * Agree with you on the user status enum and moving the color function. * Agree on using Laravel accessors and mutators. * I don't agree with creating the forUser function in the enum, that isn't the enum's responsibility it is the user model's. * I'm not sure I agree with moving the query builder functions to another object or not -- I like being able to look at the user model to know what I can do with it, without having to hunt down the custom builder class. Especially because the builder isn't reusable for any other class except users. The enums created could, in theory, be reused by other classes, but the userBuilder really can't because they depend on the user's fields specifically. While, this one I think is matter of taste, moving them to the builder geels like lowering cohesion and rising coupling to move them off to another class -- the opposite of what we want in our object structure.

Besides the comments removed 🤣🤣, i loved the way you organized the logic.

Fajne fajne ❤

replace fillable to guarded is absolute shit idea in my mind, just because the fillable property also gives ur info about columns in table without checking migrations