Great vid as always! I definitely need to think more about my error handling, because I often rely on the built in exception types which never gives me the granularity I like without delving into stack traces on sentry :D Couple of personal preferences, absolutely just trying to contribute my ideas here 12:15 - SettingType::from($request->validated('type')) can become $request->enum('type', SettingType::class) which I think has the advantage of being a bit more readable, and lets the caller know than we (probably) already validated for enum safety 25:15 - Instead of passing an anonymous array of SettingDtos, I would like to have my storeMany method have the signature storeMany(User $user, ...Dto $dto). I prefer this because by splatting in the params you can get language level type safety on the arguments instead of relying on the doc block to help -- just call with $service->storeMany($request->user, ...$dtos) and you've got type safety on both sides :)
Hej, czy mógłbyś zrobić kontynuację kursu CI/CD? Mam z tym aktualnie spory problem. Czy CD jest w ogóle jakkolwiek możliwe w oparciu o github i dockerhub w aplikacji laravel?
I love your content! I have doubt, why do you like to split your project like that? could you be more specific and maybe get into the details of how companies handle the structure of a project? does the way you structure your project has a name? like a design pattern name?
Thank you! The structure itself is not necessarily a design pattern but the entire approach presented allows you to create a better separation between business language and the application layer. It's def not DDD but it has some benefits of it. It's just a simple service + DTO pattern with things Laravel gives you for separation of concerns i.e resources and query builder classes
Thank you! The purpose of DTOs is to move data from controller/command/job/external api to the service in unified way. Model doesn't exist at that point yet
User is usually an actor in that arrangement b/c they perform an action. But when you have like a PostService, you'd need two methods. public function store(User $actor, PostDto $dto): Post; public function update(User $actor, Post $post, PostDto $dto): Post; There is nothing wrong with passing models there. It's just the purpose of DTO is to move data and the persistence of that data would happen in the service or repository based on your liking
@@saaslaravel why pass the model in at all? Surly the setting table only needs a user_id for the scope to apply correctly. And now, without a model, it has no knowledge of the entirety of the user model. And the setting module doesn’t depend on the User /auth module. Ie the setting module should not be calling any methods on $user. Ie $user->changeName(‘hdhdh. Yes this causes you to have to use events to propagate other scope to settings and is a hole other subject but. But what could you need from $user? If you cant be bothered to take a user id from the user variable, would ot not be better for the module to take a Authentication Contact that user implements?
Yes you should pass a dto, or at least an interface. Only when the model is of another bounded context. There are two distinct types of service, domain and application. An application service uses the domain. Application services are mostly used when handling application level things. Integration events between bounded contexts. Domain services do things that don’t fit into a model. Things in the domain, but not exclusive to an individual entity of that domain. I can provide blog post? For code review if wish
"Great Laravel Apps" is not your code. Great means how perform your applications in production. Speed, How many Users uses your application..etc.. I think videos like this, tell nothing. There are so many ways to build good code. This is why i dont watch videos in this format. But i like your other videos ;)
![Set up Laravel projects like a GOAT [Free course: Great Laravel Apps #1]](http://i.ytimg.com/vi/XZniGdE9Ebc/mqdefault.jpg)
![Testing has never been THIS EASY [Free course: Great Laravel Apps #3]](/img/n.gif)
I recognize a high quality youtube channel when i see one. This is one of them.
Great vid as always! I definitely need to think more about my error handling, because I often rely on the built in exception types which never gives me the granularity I like without delving into stack traces on sentry :D
Couple of personal preferences, absolutely just trying to contribute my ideas here
12:15 - SettingType::from($request->validated('type')) can become $request->enum('type', SettingType::class) which I think has the advantage of being a bit more readable, and lets the caller know than we (probably) already validated for enum safety
25:15 - Instead of passing an anonymous array of SettingDtos, I would like to have my storeMany method have the signature storeMany(User $user, ...Dto $dto). I prefer this because by splatting in the params you can get language level type safety on the arguments instead of relying on the doc block to help -- just call with $service->storeMany($request->user, ...$dtos) and you've got type safety on both sides :)
These are great suggestions! Thank you!
Man you would love C# haha. Thanks for the video!
Great Tutorial! THX. 👍
One question, what us your PHPStorm Theme? Thanks in advance.🙏
It's awesome. do more of these types of videos. all the best.🖤
Really Great Content. Do you have any platform other than youtube, for example medium/github, i'd like to see your published project!
Thanks so much! The source code of this project can be found in the description
Hej, czy mógłbyś zrobić kontynuację kursu CI/CD? Mam z tym aktualnie spory problem. Czy CD jest w ogóle jakkolwiek możliwe w oparciu o github i dockerhub w aplikacji laravel?
Hej, kontynuacja jest w planach :) CD jest możliwe z poziomu GitHub actions
I love your content! I have doubt, why do you like to split your project like that? could you be more specific and maybe get into the details of how companies handle the structure of a project?
does the way you structure your project has a name? like a design pattern name?
Thank you! The structure itself is not necessarily a design pattern but the entire approach presented allows you to create a better separation between business language and the application layer. It's def not DDD but it has some benefits of it. It's just a simple service + DTO pattern with things Laravel gives you for separation of concerns i.e resources and query builder classes
This is a really informing video I appreciate your efforts. However do you need DTOs when you can just use laravel models?
Thank you! The purpose of DTOs is to move data from controller/command/job/external api to the service in unified way. Model doesn't exist at that point yet
Passing a user model into a module?
User is usually an actor in that arrangement b/c they perform an action. But when you have like a PostService, you'd need two methods.
public function store(User $actor, PostDto $dto): Post;
public function update(User $actor, Post $post, PostDto $dto): Post;
There is nothing wrong with passing models there. It's just the purpose of DTO is to move data and the persistence of that data would happen in the service or repository based on your liking
@@saaslaravel why pass the model in at all? Surly the setting table only needs a user_id for the scope to apply correctly. And now, without a model, it has no knowledge of the entirety of the user model. And the setting module doesn’t depend on the User /auth module. Ie the setting module should not be calling any methods on $user. Ie $user->changeName(‘hdhdh. Yes this causes you to have to use events to propagate other scope to settings and is a hole other subject but. But what could you need from $user? If you cant be bothered to take a user id from the user variable, would ot not be better for the module to take a Authentication Contact that user implements?
Yes you should pass a dto, or at least an interface. Only when the model is of another bounded context. There are two distinct types of service, domain and application. An application service uses the domain. Application services are mostly used when handling application level things. Integration events between bounded contexts. Domain services do things that don’t fit into a model. Things in the domain, but not exclusive to an individual entity of that domain. I can provide blog post? For code review if wish
What code editor is that?
It's PHP storm with Catpuccin theme
hello, can you please make a tutorial on how to integrate laravel cashier please?
Yes! It's on the roadmap
"Great Laravel Apps" is not your code. Great means how perform your applications in production. Speed, How many Users uses your application..etc.. I think videos like this, tell nothing. There are so many ways to build good code. This is why i dont watch videos in this format. But i like your other videos ;)
I agree, but cannot really name the video "one of the good ways to make quality code". It gotta be a hot take and my opinion >>> your opinion 😹
@saaslaravel I can't find the code repo. Could you please check?
Updated the description!