What's going on, guys? Assalamualaikum, I welcome to Amigoscode. In this video, I want to show you how to properly structure your backend applications. So usually I get a lot of questions on how to properly structure the application, what packages you'd like to create, what classes. And basically, I just want to give you an example of how you should do things. If you're new to my channel, go ahead and subscribe, give me a thumbs up so I can keep recording these videos. Also, if you know, part of the Amiga So community, go ahead and join over 30,000 people combine. So literally smash that like button. So I can keep on recording these videos. Literally. It means a lot when you smash that like, button. So without further Ado, let's take off this video. So right here, I'm inside of IntelliJ. And right here, I want to give you an example with a Java project. Right. So more specifically with a Mayor project, but you'll see that you can take this exact same approach and then apply it to, for example, a Node application or a Python application, because there will be some similarities of what I'm about to show you. So in here, I've got IntelliJ open and let me quickly walk you through this project right here, which is a Maven project. And this should be really straightforward. So with any Maven project, you actually have your source right here. And then within, you have main and then Java and the resource, and then you have tests. Right. So the idea is that your Java code should live inside of this folder and then resource. This should be, for example, any configuration files that you might have. Or basically, if you're building a full stack application, for example, with spring boot, then this is where all the HTML CSS and all of that stuff goes into, including JavaScript files. Right. And then here you actually have the Java. So here. So basically test. And in Java, this is where you put all of your test code. Right. So again, I love testing. And I always encourage my students to test their code because it will just guarantee that whatever code you write and you deploy to real users indeed, does work. If you want to learn more about testing, go ahead and check my website where I've got a full course just on testing. So in here, you what I want to show you is a couple of things that you shouldn't really be creating for structuring the application. So what folders should you have and what goes into what? So let's start with, for example, let's say that you're building application, and this application has, for example, customer. It has orders you need to send emails, so on and so forth. Right. So the first thing that you need is a package. So here I'm going to create a package. And package really is just a folder. So the languages they just call it folders. But in Java, it's called a package. So the same with, for example, Golang is just a folder that you create. And then within the package itself, you can basically structure and organize your code. So packages is what you need in order to organize your code. So in here, let's go ahead and have a package called Calm Medals code. So usually the root folder or the root package in Java. So this is mainly in Java. We should start with your organization domain. So here come. And then, for example, your name or your company name. Right. So here let me just press enter. And in here with Java, you always have, for example, a main class. Right. So this is the main class. And let me just say main in here. And this is where the application runs. Now I said maybe we have users, we want to have orders, we want to have emails. Right. So what should you do? Well, you can take, for example, users. And from here, you know that actually Customer, for example, and a customer, it's an entity. Right. So instead of you having all of the classes bundled up into the root package, you can basically have a package for each entity. So for example, here I will have a package for a package within the main package. I'm gonna have a package for customer right here. And then let's just focus on Customer out. Right. So usually you might have a class called Customer. So this is the customer model. So this is the bean. Right. So this is the POJO itself. And then usually you might have also a class right here that performs business logic. So you might call it Customer and then service. You might also have another package that maybe it's for configuration. Right. So customer and then config. Right here. You might also have another package for the Http layer. Right. So this is where the Http requests come in. So here I can say Customer and then controller. There we go. And finally, you also might have a class for interacting with the database. So here I can say customer. And then Dow for Dao. And basically, in fact, let me change this to an interface. So usually this is an interface because you can have multiple implementations and the same goals for the service. So usually you'll see people saying customer service, and then you'll have a customer service impo for implementation. Right. So here let's just stick with customer service. But you can see how. So you can see how this is emerging. Right. So basically I went from the model Customer, and from it, I actually have a bunch of classes in here. And now I can start writing my code. You might be saying, why do I need to, for example, say, here, customer, config or customer, controller or Customer do if I'm inside of the Customer package. Well, if you have a massive, massive project, then you're going to be searching for these classes. You're gonna be searching for these classes. And searching is one feature that every IDE has, and usually they are really powerful. Right. So if you have all the classes named config inside of their respective package, then you're gonna have, like, a bunch of classes which are the same, and then it's just difficult for you to search. So this is why you basically name it. So the model, plus whether it's a config controller, do or layer. So this is the general idea, to be honest, then, basically. So here let's also say that for example, you have read the package, and here I'm going to say order. So here order. So this is one model. Right. Order. So from here, you can see that basically is the same thing. Right. So you most likely will have the same things inside a comfy controller, Dowel service. So I'm not going to copy that, but I just want you to see the overall structure here. Right. Let's also think maybe you would have an email functionality. Right. So you're going to send emails. So here package and then email. Right. So then inside let's just say that we have a class and here is going to be called the email and then sender. And this guy here. So this guy here usually is an interface. Right. And I've got a typo there. So this should be email and then send the so email and then send the right here. And it's an interface. And this is because you can have different types of email senders. Right. Maybe you are using Twilio. So here we can have maybe. So let's have a class, and then we're gonna say Twilio and then email. I think it's not till I think I send grid, the send grade, and then service, for example. Right. And this guy here implements the email sender. Right. So basically I should say implements and then email and then send it just like that. So you can see how my code is actually emerging. Right. So I didn't write any actual code, but I've got the structure in place. So also in here, let's say that basically you can get the cheese. Right. So you can take your models and then create packages from it. Now, the benefit of doing this way is that if your application becomes so huge, if the application becomes so huge. Right. So let's say that now you have, like, 50 packages. Right. And you can see that this is now a monolithic application. Right. And usually what you want to do is you want to basically have selfcontained applications that just do one thing. And this is where micro services come into play. Now here what you would do is you basically see that. Okay. So now I've got one package for customer, one package for email, one for order, so on. So forth. And to be honest, you know, the package itself can be its own microservice. So now you can start pulling things out into their own into their own project. Right. So usually in Java, maybe you want to have a multi module Maven project structure. Right. So each of these, for example, if you're in Spring book, for example, then they'll be their own spring boot application. Here. You see that now I can take each individual package and from it I can build its own microservice. So hopefully you can start to see the power of structuring the applications this way. So one other thing that you might have, for example, is so here, let's have a package and maybe you have some shared code. Right. So this is the shared code where each of these main packages or customer email and order they maybe depend on. You also might have one four DB, or actually that could have been outside, or maybe inside of shared. Right. So you could have a DB package inside of share. So here, let me just leave it outside. And one thing you need to realize is usually your team will come up with the standard of how you want to basically structure your applications. But usually this is a good starting point. So DB. And there we go. And to be honest, you can see that this is pretty much like how you would structure your application. Now, just a couple of things here. So this is the code itself. So this is where the meat and the bulk is. And then obviously inside of resources, for example, you might have migrations, so on and so forth. Right. But this is the overall idea of how to structure the application. Now let me just give you a couple of other folders I might have within your application. So here, outside of source, I might have I might have a directory. So this time is not folded. So this time is not a package, but it's a directory. So a directory and a package, they did the exact same thing to be honest. So here. So this folder, maybe you want to have one for docs. Right. So this is where you put some documentation inside. Right. And usually you can have basically folders within folders, and then basically just organize your application. Another folder you might have is. So here if I say directory, you might have one for design. So design. And this is mainly for ADR. So architectural design records. So if your team, they want to basically solve a problem, and then they came up with a solution. This is where they actually give the description of how they came with the architecture or the benefits and the drawbacks of why they chose this particular way of solving this problem. So this is where ads are used for. So here, then inside of design, I have a so you can basically Google Ad. It's really powerful, and people are using it quite a lot to be honest. Then also you might have one other folder for maybe CI. Right. So I continuous integration. There we go. Maybe if you're using Git as well. Right. So Get, you might have one four. Let's say get. I think it's dot and then get and then hub right here. And then basically you can have workflow so on and so forth. But you can see how I'm actually now structuring the application. I've got a couple of things here which are really cool. And perhaps maybe you also have one for Shell scripts. So here you would call it a directory and then scripts. And finally, one thing that you should always have is within your application. You should have a read me. So read me, dot, and then MD. So it's a markdown. And inside of this file, this is usually where you contain the information on how to get started with the project and things that you want. Basically, anyone that is onboarding into this project needs to know. So documentation is something really important that you should take into account, even though developers, they hate documentation. I used to hate documentation, but it's one thing that it's really important, because if you leave the company, then the next person that comes in is basically make it easier for that person. And so you should always follow these best practices as much as possible. But to be honest, in a nutshell, this is how you pretty much go and basically structure your application. Now you can see here. So we have the source main Java, and you can see you already have, like a couple of packages, classes as well, no code whatsoever. But you can see that it's it's kind of taking shape. So I would say follow this as a starting guide and then adapt to what makes sense to you and your organization. And also, as I was saying, for Java, this is more or less how you go about structuring things. But for example, for Golang, you know, it's a little bit different. So they have actually a set of standards that you should also follow. So in here on this get project right here. So go Lang and then standards. So project layout. And I'm going to leave this link where you can find it. But here, have a look. They give you basically the folders I should have for API assets, build, CMD, configs, deployments dogs, examples, hooks in it internal and basic. If I Scroll down, it tells you what each of these folders do. Right. So for example, internal. It's used to contain the private application and library code. So you can see that with Go line, it's a little bit more different. But I would say like for whatever language that you are building something. Right. So always research the project layout or how you should organize an infrastructure for that particular language. For Python. Again, you can do the same for JavaScript. No, you can also do the same. But usually it's kind of the same thing, but in a different format, I would say so. To be honest, this is it. If you enjoyed this video, give me a thumbs up. Also comment down below and let me know what you thought about this video. Right? So engage with me. And yeah, so it will help my channel and the YouTube algorithm to basically help me grow. If, you know, part of the Amiga Solar community, go ahead and join. The community is growing over time thousand people, and let me know what you want to see next. Yeah, let me know it was a fun video. So for now, I'll catch you on the next one. Assalamualaikum.
