Project | Links | Tecnologies | Running | License
Orderly is a cutting-edge web system designed to streamline operations for restaurant and food businesses (RMS). It draws from the principles of Domain-Driven Design (DDD) and Architectural Concepts to ensure scalability, maintainability, and a robust integration capability.
This project was built using the following technologies and architectural concepts:
- NestJS
- TypeScript
- Docker
- DDD (Domain-driven Design)
- Hexagonal Architecture
- Clean Architecture
- Kubernetes
Prerequisites: Ensure you have docker
, node>=18.16.0
& npm>=9.5.1
installed.
- Clone this project:
git clone https://github.com/tribofustack/orderly-api.git
-
Configure your environment by creating a
.env
file based on the.env.example
. -
Start the application:
npm run start:docker
- Alternatively, start the application with the docker command:
docker compose up
This will launch the application at port 3000
.
Once it's up, the Swagger documentation can be accessed at http://localhost:3000/
.
Prerequisites: Ensure you have a tool for running local Kubernetes clusters installed.
# create namespace orderly
$ kubectl create ns orderly
# set orderly namespace to default with kubectl
$ kubectl config set-context --current --namespace=orderly
# cache
$ kubectl apply -f k8s/cache
# database
$ kubectl apply -f k8s/db
# api
$ kubectl apply -f k8s/api
kubectl get pods -o wide --watch
📌 By default this will launch the application at port 30000
📌 Get the INTERNAL-IP with command: kubectl get nodes -o wide
With the INTERNAL-IP the Swagger documentation can be accessed at <INTERNAL-IP>:30000/
.
Domain-Driven Design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts. Here's a breakdown of how DDD principles have been applied in Orderly:
- Client: Identified optionally by a Brazilian CPF.
- Payment: Represents a transaction that will be used with OHS. Has an associated status (perhaps initiated, processed, confirmed).
- Order: Represents a customer's request. It has associated status (Received, Preparing, Ready, Finalized).
- Service: Represents the production of food. It has associated products and a client.
- Notification: A medium for communication with the user and the restaurant. Will utilize an ACL for integration.
- Admin: Handles promotional strategies and stock management.
- Stock: Represents the available inventory of products.
- Product: Items like Hamburger, Fries, Soda, etc.
- ProductDetails: For
Product
, attributes likeName
,Description
,NutritionalInfo
, etc., can be value objects. They don't have an identity on their own, but they describe a Product. - PaymentDetails: For
Payment
, attributes likeAmount
,Currency
,QRCode
can be value objects. - NotificationContent: For
Notification
, details likeMessage
,Timestamp
, andType
could be value objects.
- Check-in: Rooted at
Client
, withOrder
being part of the aggregate. - Check-out: Rooted at
Order
, which affects bothDeliver
andProduction
. - Communication: Rooted at the
Notification
system, interfacing via an ACL. - Billing: Rooted at
Payment
, using ACL to conform with OHS. - Admin: Rooted at
Admin
, influencing theStock
.
- ClientRegistered: Triggered when a client registers.
- ProductsSelected: Triggered when products are selected.
- OrderCreated: Triggered after order creation.
- PaymentProcessed: Triggered during the payment process.
- PaymentApproved: Triggered upon payment confirmation.
- StatusUpdatedToReceived: Triggered when order status changes.
- ClientNotified: Triggered to notify the client.
This project is licensed under the MIT License. For more information, please refer to the LICENSE file.