mayuresh0508/ride_it-main

1. Repository shape

This is a two-part project: a Java backend under back-end/Ride_It and a frontend workspace under front-end/ride-it-frontend. The backend is the only part whose internal architecture is visible here; the frontend’s implementation details are not present in the tree.

2. Backend style

The backend is a Spring Boot monolith organized by layers rather than by feature packages. The runtime entry point is RideItApplication, with app configuration in src/main/resources/application.properties. Maven is the build tool, and there is a GitHub Actions workflow for Maven-based CI.

3. Request boundary

Incoming HTTP traffic is handled by controllers in com.rideit.controller:

AuthController, AdminController, CustomerController, OwnerController, BikeController-related logic appears to live in service/DAO layers rather than a dedicated controller package, plus BankAccountController and PayementController.

These controllers are the main API boundary between the external clients and the backend.

4. Service layer

Business logic is concentrated in com.rideit.services. Each domain area has an interface and often a concrete implementation:

BikeService, BookingService-related interface only, CustomerService, OwnerService, PaymentService, BankAccountService, AdminService, plus photo services.

This layer is the central orchestration point: controllers call services, services enforce rules, and services coordinate persistence and security-related lookups.

5. Persistence boundary

Data access is separated into DAO classes in com.rideit.dao such as BikeDao, BookingDao, CustomerDao, OwnerDao, PaymentDao, BankAccountDao, UserEntityDao, and photo-related DAOs.

The repository uses a classic DAO/repository abstraction to isolate the service layer from persistence details.

6. Domain model

Core entities live in com.rideit.pojo. The main business objects are:

Bike, Booking, Customer, Owner, Payment, BankAccount, Location, DamageReport, ProfilePhoto, PhotosByString, User, UserEntity, and Admin.

BaseEntity suggests shared audit or identity fields. UserEntity / UserEntityId imply a join or mapping entity for user-role relationships.

7. API contracts and DTOs

The com.rideit.dto package contains the request/response boundary objects used to avoid exposing persistence entities directly. Examples include:

BookingRequestDto, BikeResponseDto, BikeForOwnerDto, OwnerRegisterDto, OwnerLoginRequesetDto, CustomerLoginRequestDto, CustomerLoginResponseDto, BankAccountDto, LocationDto, ProfilePhotoDto, and ApiResponse.

This indicates the backend transforms between API models and internal entities at the service/controller boundary.

8. Authentication and authorization

Security is a major subsystem under com.rideit.security.

It includes SecurityConfig, JwtUtils, CustomJwtAuthenticationFilter, CustomUserDetailsService, CustomUserDetails, and CustomAuthenticationEntryPoint.

The presence of JWT utilities and a custom filter indicates stateless token-based authentication, likely protecting role-specific endpoints for admin, owner, customer, and possibly bike/payment operations.

9. Business domains visible in the codebase

The structure suggests a ride-sharing / bike-rental platform with these functional domains:

bike inventory and bike photos, owner management, customer accounts, bookings, payments, bank account linking, and admin oversight.

Enumerations such as BookingStatus, PaymentStatus, ReviewStatus, Role, Status, and FuelType show explicit workflow/state management in the domain model.

10. Error handling

Custom exceptions in com.rideit.customException (LoginException, RegisterException, ResourceNotFoundException) indicate the service layer raises domain-specific failures rather than generic HTTP errors. These are likely translated by controller-level handling into API responses.

11. Cross-cutting configuration

CorsConfig suggests the backend is intended to be consumed by a separate frontend origin. That is an important architecture boundary: the frontend and backend are decoupled and communicate over HTTP with CORS enabled.

12. Testing and delivery

There is a minimal test scaffold in src/test/java/com/rideit/RideItApplicationTests.java, but no visible broad test suite. CI is configured via .github/workflows/maven.yml, so the main delivery path is Maven build/test validation.

13. What to diagram

An accurate architecture diagram should center on:

frontend client(s) → Spring MVC controllers → service layer → DAO/persistence → entities/database,

with JWT security intercepting requests before controller execution.

A secondary flow should show DTO mapping between controllers/services and the domain model, plus photo-related and payment-related subsystems as specialized vertical slices inside the monolith.