Domain-Driven Design (Backend)

Relevant source files

The following files were used as context for generating this wiki page:

• backend/src/app.ts
• backend/src/application/use-cases/booking/CreateBookingUseCase.ts
• backend/src/infrastructure/database/prisma/schema.prisma
• backend/src/interfaces/controllers/BookingController.ts
• backend/src/application/use-cases/auth/LoginUseCase.ts
• backend/src/domain/entities/Booking.ts
• README.md

The AtlasCleanAI backend implements Domain-Driven Design (DDD) to manage the complexities of an AI-powered cleaning service platform. This architecture separates the core business logic from technical implementation details, ensuring that the system remains maintainable as service requirements evolve.

The backend is structured into distinct layers: Domain, Application, Infrastructure, and Interfaces. The Domain layer contains the essential business rules and entities, while the Application layer orchestrates these entities to fulfill specific use cases like booking creation and authentication. Infrastructure handles data persistence via Prisma and external service integrations, and the Interfaces layer manages HTTP communication.
Sources: README.md:12-25, backend/src/app.ts:1-60

Architecture Layers

The system follows a layered architecture to enforce a one-way dependency flow towards the Domain core.

Domain Layer

The Domain layer defines the business entities, value objects, and repository interfaces. It represents the "truth" of the cleaning business, independent of databases or APIs. Key entities include Booking, User, and Cleaner.
Sources: backend/src/app.ts:7-12, backend/src/infrastructure/database/prisma/schema.prisma:35-130

Application Layer

The Application layer contains use cases that implement specific business workflows. It coordinates domain entities and infrastructure services to perform actions such as CreateBookingUseCase or LoginUseCase.
Sources: backend/src/application/use-cases/booking/CreateBookingUseCase.ts:10-20, backend/src/application/use-cases/auth/LoginUseCase.ts

Infrastructure Layer

The Infrastructure layer provides concrete implementations for repository interfaces using Prisma and manages external integrations like Stripe for payments or Atlas AI for intelligent scheduling.
Sources: backend/src/infrastructure/database/prisma/schema.prisma:1-10, backend/src/app.ts:40-55

Interface Layer

The Interface layer consists of HTTP controllers and routes. It validates incoming requests using Zod schemas and maps them to application use cases.
Sources: backend/src/interfaces/controllers/BookingController.ts:13-20, backend/src/app.ts:140-160

The diagram shows the dependency flow where external layers depend on the inner Domain layer.
Sources: backend/src/app.ts:80-130

Data Modeling

The system uses a relational schema managed by Prisma to persist domain state. The primary entities reflect the cleaning service lifecycle.

Core Entities Table

Entity	Description	Key Fields
User	Represents customers, cleaners, and admins.	email, passwordHash, role, status
Cleaner	Extends user data with ratings and skills.	rating, skills, serviceAreas, availability
Booking	Represents a scheduled cleaning service.	startTime, endTime, amount, status, address
Payment	Tracks financial transactions for bookings.	amount, status, provider, paymentIntentId

Sources: backend/src/infrastructure/database/prisma/schema.prisma:35-130

Entity Relationships

The ER diagram illustrates the relationships between core system entities.
Sources: backend/src/infrastructure/database/prisma/schema.prisma:35-145

Business Logic Orchestration

Use cases act as the entry point for business logic, ensuring that domain rules are applied consistently.

Booking Flow Logic

The CreateBookingUseCase demonstrates the interaction between multiple services. It validates time slots, calls the DynamicPricingUseCase for costs, and uses SmartSchedulingUseCase to find an available cleaner based on AI recommendations.
Sources: backend/src/application/use-cases/booking/CreateBookingUseCase.ts:22-55

The sequence diagram details the steps for creating a booking with AI-assisted pricing and scheduling.
Sources: backend/src/application/use-cases/booking/CreateBookingUseCase.ts:15-68

Request Validation and Safety

Data enters the system through the Interface layer, where it is strictly validated before reaching the Application layer.

1. Schema Validation: Controllers use validateSchema with Zod to ensure payload integrity.
2. Rate Limiting: Middlewares like apiRateLimiter protect the API from abuse.
3. Authentication: createAuthMiddleware uses JwtService to verify user identity and attach the user object to the request.
4. Error Handling: A centralized errorHandler captures domain and infrastructure errors, returning standardized JSON responses.

Sources: backend/src/interfaces/controllers/BookingController.ts:25-30, backend/src/app.ts:135-145, backend/src/shared/utils/validator.ts:5-10

Summary

The Domain-Driven Design implementation in AtlasCleanAI Enterprise provides a robust framework for managing cleaning operations. By encapsulating AI logic within specialized services and use cases, the backend maintains a clear separation between business strategy and technical execution. This structure supports complex features like dynamic pricing and smart scheduling while ensuring data integrity through Prisma-backed persistence and strict request validation.
Sources: README.md:30-45, backend/src/app.ts:80-100