One of my favorite strategies to build software these days is the vertical slices architecture. You might have heard of this by the name of vertical slices. Maybe someone said grouping by context. It's usually the same thing. You see, when you build applications, we usually group things by type. In this course, we've seen how to do things by grouping by context first and then by type, for example. With vertical slices, the idea is instead of grouping things by type, you simply group them by feature or by context.

With vertical slices, the idea is instead of grouping things by type, you simply group them by feature or by context. So, for example, let's say that you have a checkout feature. You would have models, you would have views, you would have controllers, requests, etc. We're used to creating folders for each one of those needed items. And with vertical slices, you just create a feature that slices through all the layers and groups them. So you would just have a folder and have the models, the controllers, the views, all of that in that single folder.

So you would just have a folder and have the models, the controllers, the views, all of that in that single folder. It's a bit of a mindset change, but I think it's a very interesting approach to building software. If you have things that belong together, then it's much easier to reason about a given feature. Of course, it also introduces some complications, for example. Sometimes you're not sure where to put a file. Should it go into this context or this other context? Maybe both of them use them.

Should it go into this context or this other context? Maybe both of them use them. And yeah, that's a little bit complicated. On this video, I want to show a little bit how I would approach this project using a vertical slices approach or how I like to call them just grouping things by context. Let's jump into the code. All right, so we have our application grouped by context first, and then we have our usual grouping by type approach. For this example, let's slice out the checkout feature.

and then we have our usual grouping by type approach. For this example, let's slice out the checkout feature. There's no single way of slicing out a feature. Each author has their preferences, and it's just the idea of grouping things by context. It's nothing more than that. For example, I could create a checkout folder within modules, but I could also create a checkout folder inside order because it is a part of the order feature, if you will. Let's do that.

because it is a part of the order feature, if you will. Let's do that. Let's create a directory under order called checkout. Now let's go through each one of those files and see what relates to the checkout. First, we have the controller that obviously relates to checkout. So let's drag this here, and phpStorm is going to update the namespace for us. You know what? Let's go ahead and also add a return type here so phpStorm does not complain.

You know what? Let's go ahead and also add a return type here so phpStorm does not complain. It's a JSON response. There we go. Now we also need the request, right? It's important. It's part of the feature. Let's also drag that and update the namespace. Now we can get rid of this HTTP folder. We don't have anything here. The purchaseItems action is also part of the checkout feature, so let's drag that here.

The purchase items action is also part of the checkout feature, so let's drag that here. Let's see what else we have. The OrderFulfilled event is definitely part of the checkout feature. Setting an OrderConfirmation, also part of checkout. Now we can also get rid of this folder. An OrderMissingOrderLinesException, well, I wouldn't say this is part of the checkout feature because this is a part of the Order model. So let's leave this here for now.

because this is a part of the Order model. So let's leave this here for now. Order received is also part of the checkout feature. Let's get rid of this folder as well. So the models, I don't think the models are part of the checkout feature. They are used by the checkout feature for sure, but I wouldn't say they're part of the checkout. They're part of the order concept. So let's leave this here at least for now. Providers, that's also infrastructure stuff,

So let's leave this here at least for now. Providers, that's also infrastructure stuff, so let's leave this here. And then we have views and view components. I like to leave the UI separated. I do not really enjoy having that on the slides, but that's how I like to do things. The good approach sometimes is to have a UI folder where you store views, routes, even controllers, since they relate to the user side of things.

where you store views, routes, even controllers, since they relate to the user side of things. All right, so we can also get rid of the actions folder. As you can see, we now have a folder that's strictly related to the checkout feature, and it's pretty streamlined. We have a controller, a request, an event, an event listener, and an email. And we also have an action. We have six files that were previously in several folders

And we also have an action. We have six files that were previously in several folders across the Order module, and they're now inside a single folder. If you're working on the checkout feature, all you have to look is here. You don't have to go to any other folder. Now, we could also do the same to the Order module itself. So let me close this and see what we have. We have DTOs.

So let me close this and see what we have. We have DTOs. Let's go ahead and move those into the parent folder, and we can get rid of this folder. We have exceptions. Let's also move this here and get rid of the folder. Let's move the models and get rid of the folder, and let's just leave providers, tasks, views, and view components. It didn't get so big. It's still really easy to understand,

It didn't get so big. It's still really easy to understand, and everything is together. A padding that I also like to use is to have a contracts folder like this and store everything that's a contract. So for me, a DTO is a contract, right? Let's copy those and move it to the contracts folder. PendingPayment is also a contract. Now, it does feel weird to have config and routes here,

Pending payment is also a contract. Now, it does feel weird to have config and routes here, so we can also create a folder like we have on other modules called infrastructure. We can move our providers. We can move config, and we can also have a directory called. I've seen people call this user interface. I've seen people call this UI. I like to go with UI,

I've seen people call this UI. I like to go with UI, and then we can move our view components, our views. Let's refactor this, our routes, and there we go. We can also move database into infrastructure, and we now have a very linked module where things that work together are together. That's pretty much all there is to it.

where things that work together are together. That's pretty much all there is to it. We obviously have to go into the providers and reconfigure the paths for our routes, for our configuration file, etc. I'm not going to do this in the video since you already know how to do this. I'm going to do this after I record this, and push it to the repository. If I were to close everything like this,

and push it to the repository. If I were to close everything like this, you can see that we now have a pretty small module, and everything is grouped by context. The trick with vertical slide instances is to not ever let a module grow too big. Now, you might ask two things. First, is that all there is to it? Yes, it's pretty much that. It's just having things grouped by context.

Yes, it's pretty much that. It's just having things grouped by context. Secondly, isn't this hard to work with? I can say that I personally do not have any problems whatsoever working with vertical slices. It does take a while to get used to it. I've done group-by-type my entire life, so making the switch to this different way of organizing things was a little bit weird. But I can say that if you keep your modules

of organizing things was a little bit weird. But I can say that if you keep your modules or your context, whatever you want to call them, very small and segregated, it's not hard to work with at all. In fact, I think it makes it much, much easier to work on any given feature. Like I said, I like to separate the UI. Some people don't. Some people just have the views.

Some people don't. Some people just have the views and Livewire components and view components all in a single folder, and it's fine. As long as they do not grow too big, you're probably not going to have any problems with it. With that said, grouping by type is completely fine. It's not a problem. There is no right or wrong. This is just a different way of doing things.

There is no right or wrong. This is just a different way of doing things. I hope you guys enjoyed this lesson, and I'll see you in the next one. Bye-bye.