Hey there, welcome back. On this last thing, we're going to talk about two things. First, we're going to talk about how to group our code by type, like Laravel does, within your modules. And then we're going to see how to combine that with vertical slices to have pure vertical slices within a folder, things that relate to your domain problem, and then have things like database factories and migrations and configuration files at different folders, so that within your slices, you do not have things

and migrations and configuration files at different folders, so that within your slices, you do not have things that do not relate to the problem you're solving. And it's all pretty easy, so let's jump into the code. Alright, so let's take a look at the Product module. As you can see, we actually have things grouped by type. At the same time, we have things that would not be present within the app folder in a regular Laravel application. For example, database wouldn't be there, tasks would not be there, and configuration files would not be there.

For example, database wouldn't be there, tasks would not be there, and configuration files would not be there. So first, let's see how we can isolate configuration files, database files, etc., from the core problem that we're solving. And for this, we can create something that's equivalent to the app folder within the root directory. It's pretty simple. First, let's start by creating a directory within product. We can call this source, src. Some people will call it app, and this is totally up to you.

We can call this source, src. Some people will call it app, and this is totally up to you. I prefer to call it source. Now, we do not really want anything that's inside source to have source within the namespace, and this is not even compliant with PSR-4 autoloading. So we have to instruct Composer to give whatever is in source a different namespace. Let's go into our composer.json file. Let's jump into autoload and go into PSR-4.

Let's go into our composer.json file. Let's jump into autoload and go into PSR-4. Just like we instructed Composer to give the modules directory the modules namespace, we can instruct it to give it the modules product source directory a different namespace. For example, we can say that modules product is going to be modules product source. So we are mapping this namespace to this directory. You could also let the product module have its own composer.json file and then require it as a local repository,

You could also let the product module have its own composer.json file and then require it as a local repository, but that's a little bit more complicated. Okay, let's start by dumping our autoloader like this, composer dump-autoload, and then let's pick what we want to have on the source folder, and that is everything that would be in the app folder in a regular level application. So events, models, providers, warehouse, correctItem, correctItemCollection, and productDTO. And let's move all of that into the source directory.

correct item collection, and product DTO. And let's move all of that into the source directory. As you can see, the namespace didn't change, and that's because we've mapped this path to this namespace within our composer.json file. Now, we only have database and the config file outside of the source directory. And if you're doing this, I suggest that you follow Laravel's conventions. So let's rename this to lowercase database.

Laravel's conventions. So let's rename this to lowercase database and update our files. I went ahead and renamed factors and migrations to their lowercase equivalents, which is what you would find within the database folder in Laravel. Now, we want to do the same thing with configuration files, so let's create a new directory called config, and then we can move this here.

so let's create a new directory called config, and then we can move this here. Now, we just need to fix our paths, so let's go into our service provider. Migrations is now lowercase, and you have a config directory. We must also go back in another directory. Remember, we are within source providers, so we have to go back to source, then go back to product, and then access config.

so we have to go back to source, then go back to product, and then access config. We must also fix our routes.php location, and that's something you would put within HTTP. So let's also move that here. And now within our RouteServiceProvider, we're going to update this to go into the correct directory and search for the correct file. Let's rerun our tests, and we are not running migrations,

Let's rerun our tests, and we are not running migrations, so let's fix this as well. Remember, we are within source providers, so we go back to source, we go back to the route, and then we can access config and database. Let's rerun our tests. Okay, we're passing, and as you can see now, within the source directory, we have everything that's related to the problem we're solving.

within the source directory, we have everything that's related to the problem we're solving, and at the route, you have things like database, configuration files, and tasks that might make it easier for you to navigate the project. Another benefit is, since we are following Laravel's conventions, we can use things like the Laravel modules packages or Laravel IDEA to generate files for us. For example, if we go into Laravel IDEA in phpStorm and modules system,

For example, if we go into Laravel IDEA in phpStorm and modules system, and we change this to directory modules with composer.json packages, let's save this, and let's say that I want to add a new model into Product. Let's create a model. I can specify the module, and we're going to call it Sale. Let's run a test. We want a migration. Let's run this.

Let's run a test. We want a migration. Let's run this. So let's look at source models. We have the Sale model, and then within database/migrations, we also have the migration. So if you plan to use code generation tools, following the conventions does make sense, even if you're using a module structure. Our main goal with modularization,

even if you're using a module structure. Our main goal with modularization, or one of the main goals, is to group things by context, and they are. They are within the product module. Inside that, we're grouping by type, but we have a good entry point. We have a good reference. We know that everything within this module is related to the product module.

We know that everything within this module is related to the product module. And then we also know that if we go into the source folder, that's what's related to the problem we're solving and everything else on the product directory relates to it, but not directly. So you still have tasks separated, you still have database, config, etc., all separated from source, which would be the equivalent of the app folder.

all separated from source, which would be the equivalent of the app folder. Now, that's one thing. If you go within the source directory, we have things nicely grouped by type. We could even go further and create a directory for our custom collections and move this here, and then one for, for example, DTOs, and move those two here.

and then one for, for example, DTOs, and move those two here. And there we go, nicely grouped by type. However, another thing that you can do is if you want to have vertical slices within the source directory, that also makes sense. That way, you can have your views within the root module folder, your configuration and database files also within that folder,

your configuration and database files also within that folder, and have your vertical slices within the src folder that might introduce less noise for you. So if we go into the order module, we could have a src directory with checkout, contracts, and infrastructure, and then with those files, and have everything else outside of that src directory. That also works wonderfully.

and have everything else outside of that source directory. That also works wonderfully. If you think having it like this introduces a lot of noise, or if you want to use code generation tools and not build your own, it does make sense to have that source folder. As you can see, it's super simple to set that up, and you can make sure that your application falls to your standards.

and you can make sure that your application falls to your standards. If you prefer to have pure vertical slices, that's fine. If you want to group by type and follow all of those conventions, that's also fine. And if you want to have your src folder as your entry point for your slices, that's also perfectly fine.

as your entry point for your slices, that's also perfectly fine. All you have to do is make sure that composer.json is properly configured. All right, this is all for this lesson. I'll see you on the next one. Bye-bye.