vaibhavsandi/rentmanagementsystem_backend

1. This is a Spring Boot monolith for rent management, organized as a layered backend application. The main runtime entrypoint is DemoApplication, with configuration and component scanning rooted under com.app.rentmanagement.demo.

2. The domain is centered on property-rental operations: flats, renters, rent payments, rent revisions, parking details, expenses, settlements, pending rent, and dashboard summaries. Those concepts are represented consistently across entities, DTOs, services, controllers, and repositories.

3. The primary request flow is standard controller → service → repository → entity. Controllers expose the API, services implement business rules, repositories provide persistence access, and entities model the database state. DTOs are used at the API boundary so controllers do not directly expose persistence models.

4. Persistence is built on Spring Data JPA-style repositories with a relational database model. The entity layer includes User, Flat, Renter, RentPayment, RentRevision, ParkingDetails, Expense, and Settlement, plus enums such as PaymentMode, RenterStatus, and UserRole.

5. Authentication and authorization are a distinct subsystem. AuthController works with JwtUtil, JwtAuthenticationFilter, CustomUserDetailsService, and CustomUserDetails to secure the API with JWT-based login and request filtering. User is the security principal stored in the domain model.

6. There is a clear separation between API contracts and internal models through the mapper layer. Mappers convert between entities and DTOs for flats, renters, parking details, rent payments, revisions, expenses, and settlements, which keeps controller payloads stable and limits coupling to persistence shape.

7. Business services are split by feature area, each with its own interface and implementation pair. The service layer includes Flat, Renter, Parking, RentPayment, Expense, Settlement, PendingRent, and Dashboard services, indicating a modular but single-process architecture rather than separate microservices.

8. Reporting is a separate output path from the core CRUD flows. ReportController delegates to ExcelReportService and PdfReportService, which likely aggregate data from the same domain services/repositories and render downloadable reports in spreadsheet and PDF formats.

9. Cross-cutting concerns are centralized. GlobalExceptionHandler turns domain and validation failures into structured API errors, while custom exceptions such as ResourceNotFoundException, DuplicateRecordException, BadRequestException, and FlatDeleteException define business-specific failure boundaries.

10. Auditing and shared utilities support the domain model. BaseEntity and AuditAwareImpl indicate created/modified metadata tracking via JPA auditing, while AppConstants, CommonUtil, and DateUtil provide shared application-level helpers used across features.

11. AppConfig and SwaggerConfig show that the app also exposes API documentation and general Spring configuration. Swagger/OpenAPI is part of the developer-facing interface, but it does not change the runtime business flow.

12. Overall, the architecture is a classic layered Spring Boot backend with a security boundary in front of feature controllers, a service-centered business layer, repository-backed persistence, and specialized report/export paths for operational outputs.