Benaa Orbit
API Documentation
📋 Overview
About This Project
Benaa Orbit
Benaa Orbit is built following Clean Architecture principles,
which promotes
separation of concerns
and maintainability. The architecture is organized into distinct layers, each with its own
responsibility:
- Domain Layer: Contains core business entities and value objects. This
layer is independent
of external frameworks and represents the business logic of the application.
- Application Layer: Contains use cases, DTOs (Data Transfer Objects),
interfaces, and
application-specific business logic. This layer defines what the application does but
not how it does it.
- Infrastructure Layer: Contains implementations of interfaces defined in
the Application layer,
including database contexts, services, external API integrations, and data persistence
logic.
- Web API Layer: Contains controllers, middleware, and API-specific
configurations. This is
the entry point for HTTP requests and handles routing, authentication, and response
formatting.
This layered approach ensures that business logic remains independent of infrastructure
concerns, making the
codebase more testable, maintainable, and adaptable to changes in external dependencies.
Clean Architecture Layers
The following diagram illustrates the layered architecture of Benaa Orbit, showing how different
layers interact and depend on each other:
flowchart TB
subgraph WebAPI["Web API Layer"]
Controllers["Controllers
Middleware
API Configuration"]
end
subgraph Infrastructure["Infrastructure Layer"]
Services["Services
Database Context
External APIs"]
Repositories["Repositories
Data Persistence"]
end
subgraph Application["Application Layer"]
Interfaces["Interfaces
Contracts"]
DTOs["DTOs
Request/Response Models"]
UseCases["Use Cases
Business Logic"]
end
subgraph Domain["Domain Layer"]
Entities["Entities
Value Objects
Domain Models"]
end
WebAPI -->|Uses| Application
Infrastructure -->|Implements| Application
Application -->|Depends on| Domain
Infrastructure -->|Works with| Domain
style Domain fill:#e8f5e9,stroke:#4CAF50,stroke-width:3px
style Application fill:#e3f2fd,stroke:#2196F3,stroke-width:3px
style Infrastructure fill:#fff3e0,stroke:#FF9800,stroke-width:3px
style WebAPI fill:#f3e5f5,stroke:#9C27B0,stroke-width:3px
Dependency Flow: The arrows show the direction of dependencies. The inner
layers
(Domain) have no dependencies on outer layers, while outer layers depend on inner layers. This
ensures that business logic remains independent and testable.
Third Parties Used
The following diagram shows the third-party services and external dependencies used in the Benaa Orbit
system:
flowchart TB
subgraph System["Benaa Orbit System"]
API["Web API
Controllers"]
App["Application Layer
Use Cases"]
Infra["Infrastructure Layer
Services"]
end
subgraph ThirdParty["Third Party Services"]
EmailService["Email Service
SMTP Provider"]
SMSService["SMS Service
SMS Gateway"]
Database["Database
SQL Server"]
end
API -->|Uses| App
App -->|Uses| Infra
Infra -->|Sends Emails| EmailService
Infra -->|Sends SMS| SMSService
Infra -->|Stores Data| Database
style System fill:#e3f2fd,stroke:#2196F3,stroke-width:3px
style ThirdParty fill:#fff3e0,stroke:#FF9800,stroke-width:3px
style EmailService fill:#e8f5e9,stroke:#4CAF50,stroke-width:2px
style SMSService fill:#e8f5e9,stroke:#4CAF50,stroke-width:2px
style Database fill:#e8f5e9,stroke:#4CAF50,stroke-width:2px
System Components Architecture
This diagram illustrates the system components and how they interact with each other:
flowchart TB
subgraph Client["Client Layer"]
WebApp["Web Application"]
MobileApp["Mobile Application"]
end
subgraph API["API Layer"]
AuthController["Auth Controller"]
Middleware["Middleware
Authentication
Validation"]
end
subgraph Services["Service Layer"]
AuthService["Authentication Service"]
EmailService["Email Service"]
SMSService["SMS Service"]
TokenService["Token Service"]
end
subgraph Data["Data Layer"]
DB["Database
SQL Server"]
Cache["Cache
Redis/Memory"]
end
subgraph External["External Services"]
SMTP["SMTP Server"]
SMSGateway["SMS Gateway"]
end
WebApp -->|HTTP Requests| AuthController
MobileApp -->|HTTP Requests| AuthController
AuthController -->|Uses| Middleware
AuthController -->|Calls| AuthService
AuthService -->|Uses| TokenService
AuthService -->|Uses| EmailService
AuthService -->|Uses| SMSService
AuthService -->|Reads/Writes| DB
TokenService -->|Stores| Cache
EmailService -->|Sends| SMTP
SMSService -->|Sends| SMSGateway
style Client fill:#e8eaf6,stroke:#667eea,stroke-width:3px
style API fill:#f3e5f5,stroke:#9C27B0,stroke-width:3px
style Services fill:#e3f2fd,stroke:#2196F3,stroke-width:3px
style Data fill:#fff3e0,stroke:#FF9800,stroke-width:3px
style External fill:#e8f5e9,stroke:#4CAF50,stroke-width:3px
Data Flow Diagram
This diagram shows how data flows through the system during authentication and registration processes:
flowchart LR
User[User Input] -->|Email/Phone| WebApp[Web Application]
WebApp -->|Request| API[API Controller]
API -->|Validates| Validator[Input Validator]
Validator -->|Valid Data| Service[Business Service]
Service -->|Query| DB[(Database)]
DB -->|Data| Service
Service -->|Generate| Token[Token Generator]
Token -->|Encrypted Token| Service
Service -->|Send| Email[Email Service]
Service -->|Send| SMS[SMS Service]
Email -->|OTP/Email| User
SMS -->|OTP| User
User -->|OTP/Token| WebApp
WebApp -->|Verify| API
API -->|Verify| Service
Service -->|Check| DB
DB -->|Result| Service
Service -->|Response| API
API -->|JSON Response| WebApp
WebApp -->|Display| User
style User fill:#e8eaf6,stroke:#667eea,stroke-width:2px
style WebApp fill:#f3e5f5,stroke:#9C27B0,stroke-width:2px
style API fill:#e3f2fd,stroke:#2196F3,stroke-width:2px
style Service fill:#fff3e0,stroke:#FF9800,stroke-width:2px
style DB fill:#e8f5e9,stroke:#4CAF50,stroke-width:2px
API Documentation Structure
This documentation provides comprehensive information about the API endpoints, workflows, and
implementation
guidelines. Use the navigation panel on the left to explore different features and their
documentation.