How to Architect Your Project's Directories

One of the important things that are overlooked by developers while building applications is the folders' structure and names.

Where did it all go wrong? 😬

While learning a new framework, for example, We tend to keep using the structure that we learned during the tutorial in our production code.

How does this structure look mainly?

It describes what are the main building blocks of the framework, and not the application we were building in the tutorial.

What building blocks? 🧙🏼‍♂️

• Controllers
• Services
• Views
• Models
• DTO

Is it really this bad? 🤷🏽
Well, for the sake of understanding how the framework works, it's totally valid.
However, when we go on to build production systems with complex business requirements, this approach becomes impractical.

Why do it differently?

In big systems, while debugging or trying to understand how a piece of code works it would be helpful to view the folders as an open book that tells us:

• What does this system do.
• What are the components that build the system.
• What is the hierarchy the components follow.

Let's look at some examples 👴🏼

Here is one of the Standard naming conventions of a Spring Boot application.

It's like saying, I am building this thing, I will use those tools

On the other hand, we have a naming convention that describes the application

It's clear from this structure what's going on:

• Delivery has Request and Shipment components under it.
• We also have a Payment component.

it's like saying I am building a restaurant and this is the layout

Conclusion 👇🏼👇🏼

The folder structure of our application is very crucial to help us understand what is going on in the system and we should take care of making it as clear and descriptive as possible.