Sometimes we need to create a new service or refactor the existing one. Most of the time, we spend a couple of hours initializing the application - Node application setup, creating files, folders, etc. The way we structure the folders’ skeleton can be something similar to other services in our repos or based on a service we have done in the past.
This moment is highly important! If we stop and take the time to plan before starting this process, it will be worth it in the long run.
In this article, we will do it by creating the folders’ skeleton using the Clean Architecture approach.
Table of contents
- Why software architecture is so important
- About Clean Architecture
- Node API Service with Clean Architecture
- Folders skeleton
- Summary
Why Software Architecture Is so Important
In a large project, we want it to be easy to maintain, stable (not quick & dirty), and open to new features as quickly as possible.
To achieve that, we need to separate our files and folders into components with different responsibilities that can change independently without affecting other components.
Clean Architecture
In short, Clean Architecture is a system architecture guideline proposed by Robert C. Martin (Uncle Bob).
You can read about it here and here and here.
The main concept can be shown by Robert Martin’s illustration:
Each circle represents a different area in our software. According to the dependency rule, the outer layer can depend on inner layers but not on any layer outer from it, which means that as a general rule, the deeper the layer, the less it is prone to changes.
Since this is a little bit abstract, let us demonstrate what it looks like in Node API Service.
Node API Service with Clean Architecture
We will start creating a Node service that has an API and Database.
In Clean Architecture, we will have these layers:
Domain layer - the abstract layer, responsible for all of our business data, our business functions and entities, but abstracted - interfaces and abstract classes.
Application layer - the logic layer, each file here is responsible for a flow or use case in our project.
Adapter layer - the API presentation layer, which includes routes, controllers, etc.
Infrastructure layer - database configurations, implementations of the entities, providers, etc.
Folders skeleton
The layers break down into these folders: domain, use cases, API, and infrastructure.
In the Artlist world, it can be implemented as a service for managing artists and songs.
First, let us see what it looks like for each folder:
domain - contains files such as enums, interfaces, models, etc.
In Artlist, it would be the place for artist and song properties and abstract classes of the logic for each flow.
usecases - contains files of the project logic, flow, and use cases.
Each file can present a separate flow, like "download song use-case" or all song use-cases.
api - contains files such as controllers, interceptors, guards, etc.
For Artlist, this is the API for the client side to get the artist and song data.
Here we can call from the controller 'a to use case 'a.x' and use case 'a.y'. If we do so, we make a dependency from the adapter layer to the application layer. That is ok because the dependency is from the outer layer to a deeper layer.
infrastructure - contains database configurations - table entity implementations, external providers, DAL repositories, etc.
Here we can implement the abstract classes declared in the domain layer - also, the database entities and ORM.
Now we have a basic folder structure for Node API service using Clean Architecture.
You can save it as a template repo and start other services from it.
Summary
In this article, we learned the basics of Clean Architecture. First, we translated it to the Node world, then demonstrated how to build a project skeleton for Node API service using Clean Architecture and finally showed how it can be implemented in the Artlist world.
Thanks for reading!
Top comments (0)