A simple API built with Hapi.js that follows DDD + Clean Architecture principles
The developer of this repository has not created any items for sale yet. Need a bug fixed? Help with integration? A different license? Create a request here:
git clone [email protected]:jbuget/nodejs-clean-architecture-app.git cd nodejs-clean-architecture-app npm install npm test npm start
In a browser, open http://localhost:3000/hello.
Software design is a very hard thing. From years, a trend has appeared to put the business logic, a.k.a. the (Business) Domain, and with it the User, in the heart of the overall system. Based on this concept, different architectural patterns was imaginated.
One of the first and main ones was introduced by E. Evans in its Domain Driven Design approach.
The application follows the Uncle Bob "Clean Architecture" principles and project structure :
app └ lib → Application sources └ application → Application services layer └ security → Security tools interfaces (ex: AccessTokenManager.js, to generate and decode OAuth access token) └ use_cases → Application business rules └ domain → Enterprise core business layer such as domain model objects (Aggregates, Entities, Value Objects) and repository interfaces └ infrastructure → Frameworks, drivers and tools such as Database, the Web Framework, mailing/logging/glue code etc. └ config → Application configuration files, modules and services └ service-locator.js → Module that manage service implementations by environment └ orm → Database ORMs middleware (Sequelize for SQLite3 or PostgreSQL, Mongoose for MongoDB) └ mongoose → Mongoose client and schemas └ sequelize → Sequelize client and models └ repositories → Implementation of domain repository interfaces └ security → Security tools implementations (ex: JwtAccessTokenManager) └ webserver → Hapi.js Web server configuration (server, routes, plugins, etc.) └ oauth → Hapi.js authentication strategies and schemas └ server.js → Hapi.js server definition └ interfaces → Adapters and formatters for use cases and entities to external agency such as Database or the Web └ controllers → Hapi.js route handlers └ routes → Hapi.js route definitions └ serializers → Converter objects that transform outside objects (ex: HTTP request payload) to inside objects (ex: Use Case request object) └ node_modules (generated) → NPM dependencies └ test → Source folder for unit or functional tests └ index.js → Main application entry point
The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.
Server, routes and plugins can be considered as "plumbery-code" that exposes the API to the external world, via an instance of Hapi.js server.
The role of the server is to intercept the HTTP request and match the corresponding route.
Routes are configuration objects whose responsibilities are to check the request format and params, and then to call the good controller (with the received request). They are registered as Plugins.
Plugins are configuration object that package an assembly of features (ex: authentication & security concerns, routes, pre-handlers, etc.) and are registered at the server startup.
Controllers are the entry points to the application context.
They have 3 main responsibilities :
A use case is a business logic unit.
It is a class that must have an
executemethod which will be called by controllers.
It may have a constructor to define its dependencies (concrete implementations - a.k.a. adapters - of the port objects) or its execution context.
Be careful! A use case must have only one precise business responsibility!
A use case can call objects in the same layer (such as data repositories) or in the domain layer.