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.