This is the fourth article in our series on clean architecture (the previous ones are listed at the bottom of the page), and we’re getting more technical with an introduction to implementing the principles in a Node.JS API with Express.
Let’s take a look at the overall structure of a project and the details of the main concepts (entities, adapters, injection…).
<h2>Organization of main directories</h2>
Let’s start by taking a look at the general directory structure. As is often the case, all our API source code is grouped together in the “/src” directory. Next, let’s take a look at the <a href="https://dev.to/nlapointe/clean-architecture-infrastructure-vs-core-492k" target="_blank" rel="noopener nofollow">Core vs. Infrastructure</a> distinction:
<img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iwanr9gnjig93zr2lnjh.png" alt="Structure tree">
<h2>The heart of the application in “/core”</h2>
This is where use cases, business entities and business rules reside. Not dependent on any external framework or library, it represents the bare minimum needed to run our application: it’s the functional core of our application. It is itself divided into several sub-directories.
<h3>Use cases</h3>
In “/core/use-cases”, we find the business use cases. Each use case has its own typescript file with, if required, its own input and output types (what goes into the use case and what comes out). There are two schools of thought:
<ul>
<li>A sub-folder with a grouping of use cases. Example: A user subfolder in which I group all user cases.</li>
<li>All use cases at the root of use-cases, with no particular tree structure.</li>
</ul>
I personally prefer the second solution, all “flat”, for the simple reason that you never have to ask yourself the question “where do I put / where has this use case been put?”. A simple example: do you put a user’s address in “user” or “address”? There are as many answers as there are developers, so you might as well not put a sub-folder!
An example of a use case that allows you to obtain a book by its id:
<pre><code class="language-ts">class GetBook {
 private bookRepository: BookRepository;
 private logger: Logger;

 constructor() {
 this.bookRepository = container.resolve&lt;BookRepository&gt;(&#x27;BookRepository&#x27;);
 this.logger = container.resolve&lt;Logger&gt;(&#x27;Logger&#x27;);
 }
 async execute(id: string): Promise&lt;Book | &#x27;BOOK_NOT_FOUND&#x27;&gt; {
 this.logger.debug(&#x27;[Get-book usecase] Start&#x27;);
 const data = await this.bookRepository.findById(id);
 return data ?? &#x27;BOOK_NOT_FOUND&#x27;;
 }
}
export default GetBook;
</code></pre>
<h3>Entities</h3>
The “/core/entities” directory contains our business data models, such as “User” or “Product”. These are simple objects that represent the concepts of our domain, and bring together their business rules.
Let’s take the example of our “User”, and more precisely of a user who is not logged in, and therefore not known to the API:
<pre><code class="language-ts">export class NotExistingUser extends User {
 constructor() {
 super();
 }

 public hashPassword(notHashedPassword: string) {
 const hmac = createHmac(&#x27;sha512&#x27;, this.config.salt);
 hmac.update(notHashedPassword);
 return hmac.digest(&#x27;hex&#x27;);
 }
}
</code></pre>
Here, we have a class that extends User and thus retrieves its properties, and a method that belongs to it, that is, “its” business rule: You hash a password (to create your account or connect to it).

News, updates, and discussions about everything happening in and around the Node.js runtime.

Node.js developers

This post provides an introduction to implementing the principles of clean architecture in a Node.JS API with Express. It covers the overall structure of the project and the main concepts such as entities, adapters, and injection.

[Part1] Introduction to the principles of clean architecture in a NodeJs API (Express)