تماشای این درس نیاز به اشتراک حرفه‌ای دارد.

Course Wrap-Up0:00

Hey folks, that's a wrap. If there's something I wish I was able to provide with this course is really a new way of thinking. Not necessarily the right way for everything, but really just new ideas, something that you can use in your projects. And I also hope I was able to give a fairly tactical view of those and ways to implement those ideas, something that you can use in your code base as soon as you finish this course. Some things were overengineered for the sake of teaching new ideas, and some things were also simplified for the sake of fitting into a simple Laravel application. One of my goals with this course was to first help you understand how modules work. I want you to be able to go into an application that you'll work in today, and even if it's not modularized, even if you don't have the modules logically separated, I want you to be able to delineate which modules exist within the

Understanding Modules0:48

you'll work in today, and even if it's not modularized, even if you don't have the modules logically separated, I want you to be able to delineate which modules exist within the application and also how they communicate with each other. That's one of the most important things. Secondly, I hope that you were able to learn some tactical ideas on how to implement patterns that we use to make those modules chat with each other. My goal with this course was for it to be very practical, and I really hope I achieved that. I want you to be able to understand how modules work, and if you go into, for example, an application that you'll work in, even if it's not modularized, I want you to be able to delineate all of the modules that exist within that application and how they communicate with each other, even if it's not very well defined. I try to present most things in such a way that you'll be able to apply that

Modularization Trade-Offs1:34

that exist within that application and how they communicate with each other, even if it's not very well defined. I try to present most things in such a way that you'll be able to apply that immediately after watching a lesson, that is, that you would be able to watch a lesson, jump into your code, and improve it somehow. As I said many times throughout the course, there's no silver bullet. So when you decide to go for a modularized architecture, you're introducing complexity, and when I say complexity, it isn't necessarily bad complexity. It's essential complexity. You might also have additional actors in your application. You might have more bridges, for example, DTOs and services. Those are what I call bridges. You have pieces that aid you in the communication between different modules that might result in, for example, a less rich domain model. But again, as we've seen in this course, everything is a trade-off, and modularization does not differ

Strategic Thinking Over Code2:18

communication between different modules that might result in, for example, a less rich domain model. But again, as we've seen in this course, everything is a trade-off, and modularization does not differ in that aspect. But if I had to pick the most important things, in my opinion, based on what I've shown in this course, it's not really the code. It's the strategies. It's how you think about your modules, and how you think about coupling, how you think about passing information through different contexts, how you think about cross-boundary communication. There are many different implementations that aim to do the same thing, so I would try not to focus too much on it. Really, what I want for you is to be able to understand what components exist in your application, when does it make sense to reduce coupling between different components, and when does it make sense to have a dependency on something that lives in a different module. When is it

Communication Patterns Recap3:03

when does it make sense to reduce coupling between different components, and when does it make sense to have a dependency on something that lives in a different module. When is it over-engineering for your application, and when is it required? That's what I hope to have passed with this course. And obviously, presenting different strategies for you to be able to implement that in your code base, whether you're using services and DTOs to pass information through different modules, whether you're publishing events, the goal is to create cohesive modules that are able to talk to each other in a friendly way, if that makes sense. With that said, I really hope that you enjoy this course, and if you have any doubts, any suggestions, feel free to ask them and to leave them somewhere here. Again, thank you so much for watching this course. It is a huge pleasure to be able to teach this on Laracasts, and I'll see you around. Bye-bye.

Final Thanks and Goodbye3:47

and to leave them somewhere here. Again, thank you so much for watching this course. It is a huge pleasure to be able to teach this on Larcast, and I'll see you around. Bye-bye.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟