Hi there, how's it going? Welcome to our first lesson. Well, actually second lesson, but the first one where we're going to actually code. For this example project, we're going to go with a very standard e-commerce application. And as you can see, this is a regular Laravel application. We have a few models, so we have a Product, we have an Order, which means someone bought something. We also have an OrderLine to represent the different items inside an order. We have CartItems, so people can add stuff to their cart. And we have a User and a Shipment model. Pretty standard. On this first lesson, we're going to split our application into different modules.

And we have a User and a Shipment model. Pretty standard. On this first lesson, we're going to split our application into different modules. Now, the first thing I want you guys to see here is how a Laravel application is structured by default. As you can see, we have everything inside the app directory, and things are grouped by type. So, inside console, we have the Kernel and console commands. Inside models, we have models. Inside HTTP, we have some folders, but inside controllers, we have, again, controllers. So, we're grouping things by type. Once we start splitting our application into different modules, we can follow that same structure, but we can also

things by type. Once we start splitting our application into different modules, we can follow that same structure, but we can also follow different structures. Maybe we want to follow a domain-driven design approach. Maybe we want to go with clean architecture. Those are all valid choices. And the reason I'm saying this is because when we talk about modularization, you will often find that conversation alongside domain-driven design, clean architecture, ports and adapters, etc., etc., etc. So, this is not the only way to organize your application, even though it is a fantastic way. Never mind. Let's start splitting our application. Before we do that, let's take a look at the

your application, even though it is a fantastic way. Never mind. Let's start splitting our application. Before we do that, let's take a look at the Laravel framework project on GitHub. This is the source folder. So, inside source, we have the limited folder. And take a look at this. Those are modules. So, the framework itself adopts the concept of modules. We have a mail module. We have a queue module. We have a Redis module. And those modules talk to each other. For example, a queue might use Redis as a driver, so it will communicate with the Redis driver. And it does this usually through contracts or events. And we're going to cover this later on in the series. I just wanted to show

with the Redis driver. And it does this usually through contracts or events. And we're going to cover this later on in the series. I just wanted to show you this to see that modules are not something out of this world. They're pretty common. We often do them without really realizing we're working with modules. And the Laravel framework is a great example of a modularized project. Let's go back into our project. So, I wrote down some of the modules I could think of. We're going to have a Product module, which is going to have the Product model and the CartItem model. We're going to have an Order module, which is going to have the Order model and an OrderLine. And this Order module

model and the CartItem model. We're going to have an Order module, which is going to have the Order model and an OrderLine. And this Order module is probably where we want to purchase our items. This is where we're going to handle payment, etc., etc., etc. We're going to have a payment module, which is only going to have the PaymentProcessor, at least for now. And then finally, we're going to have a shipment module, which is going to be responsible for processing those shipments. The first thing I'm going to do is I'm going to create a new directory. If you ever look for content about modularization, you'll notice that people usually refer to this directory as source, denoted as src, or modules. Some packages also name it app/modules.

modularization, you'll notice that people usually refer to this directory as source, denoted as src, or modules. Some packages also name it app/modules. For this course, we're going to go with modules. There we go. Now, I want to create some folders inside this modules directory. One for each one of the modules. So, I'm going to create a product module, an order module, a payment module, and finally a shipment module. Now, you might be thinking, you just have to drag and drop those into the modules, right? Well, not yet. You see, if you look at, let's pick the product module. Notice the namespace. We have a namespace called app/models.

You see, if you look at, let's pick the Product module. Notice the namespace. We have a namespace called app/models. An app is mapped to this app folder. Notice that here we have an uppercase on the A, and here we have app as lowercase. This is what we call PSR-4 autoloading. If we go into our composer.json file, you're going to notice that we have an autoload section, and we have the PSR-4 autoloading denoted here. And we're mapping the app namespace to the app directory, and we're also mapping, for example, database/factories to database/factories. So, what we want to do before we do any of this is

and we're also mapping, for example, database factories to database factories. So, what we want to do before we do any of this is we want to add a new namespace. We're going to call it modules, and we're going to map it to the modules directory. Once that's done, we want to run composer dump-autoload. And what the command does is it regenerates the composer autoload files. Okay, now php knows that it can load classes from this modules directory. Now we can finally drag and drop those. For this course, we're going to follow the standard Laravel structure. So, we're going to group by type inside those modules. I'm going to

drag and drop those. For this course, we're going to follow the standard Laravel structure. So, we're going to group by type inside those modules. I'm going to create a models directory for each one of those. There we go. And now I can simply drag and drop those. And as you can see, PHPStorm automatically updates the namespace based on what we have configured inside our autoload section on composer.json. I'm going to do the same for the other models. Okay, there we go. So, now we have four modules. They only have a models directory, but we managed to split our application a little bit. Now, going back to the autoloading piece, let's go into php artisan tinker real quick.

but we managed to split our application a little bit. Now, going back to the autoloading piece, let's go into Tinker real quick. And I'll try to instantiate one of those classes. Let's try this one. So, I'll say new modules\order\models\Order. And as you can see, we get an object. Now, if I were to go into composer.json and remove this and dump the autoloader, let's go back to Tinker. If I tried to instantiate it, the class was not found. So, it's important, it's imperative, that you map your modules directory to the modules namespace. Let's dump the autoload once again. Let's go into Tinker. And there we go.

you map your modules directory to the modules namespace. Let's dump the autoload once again. Let's go into php artisan tinker. And there we go. We can instantiate it. So, this is the first step. It is splitting your application, figuring out the different modules. And you don't have to be extra precise here. You can always create sub-modules in the future or extract a set of functionality into a different module. Don't worry so much about it. This is also something that can be done incrementally if you're working on an existing application. You don't have to split your entire application. Maybe you can get a complex feature and extract it to its own module, or the next time you're building something new, you can build that inside a new module.

Maybe you can get a complex feature and extract it to its own module, or the next time you're building something new, you can build that inside a new module. That's one of the great things about modularization. You don't have to follow the same strategies for every module. So, remember when I talked about domain-driven design, cleaner texture, etc. That's the beauty of it. You can use different strategies for different modules with different needs. If you have a more complex module that would benefit from domain-driven design, go for it. If it's simple enough and you're comfortable with the default level structure, go for it as well. There's no rule. That's pretty much all we're going to do for this lesson. On the next lesson, we're going to talk about service providers, which we have in our default application. We have a few of them.

That's pretty much all we're going to do for this lesson. On the next lesson, we're going to talk about service providers, which we have in our default application. We have a few of them. We're going to implement those inside our modules. And service providers are what give our application life. It's what's going to give our modules life. It's going to give them behavior. It's going to let Laravel know where to load things from, for example, migrations, views, configuration files, all of that. Before we wrap up this lesson, I want to talk about a small trade-off. You might realize that since we went from the app directory, from the default structure, to our modules directory, most of the commands we use for scaffolding won't work. For example,

the app directory, from the default structure, to our modules directory, most of the commands we use for scaffolding won't work. For example, make:model will not work because it will generate a model on the app/Models directory. This is pretty annoying, but fear not. There are packages that handle modularization, and they will give you those commands back again. For the majority of the course, we're going to do things manually because the purpose of this is for you to learn new things. But at some point, we're going to recover those packages, and I'll teach you how to use them to have more productivity. So you're not going to lose those commands. Don't worry about it. Alright, that's pretty much it for this lesson, and I'll see you on the next lesson to talk about

productivity. So you're not going to lose those commands. Don't worry about it. Alright, that's pretty much it for this lesson, and I'll see you on the next lesson to talk about service providers. Bye-bye.