nasablueberry/alo

1. Overall shape

- This is a two-tier MERN system: a Node/Express backend exposes JSON APIs, and a React/Vite frontend consumes them.

- The domain is scholarship aid management for Bangladesh: student intake, provider programs, application review, disbursement, and admin oversight.

2. Backend boundary

- The backend is the system of record and contains the business rules.

- It is organized into controllers for request handling, routes for API wiring, middleware for auth/validation/error handling, services for domain logic, and models for MongoDB persistence via Mongoose.

3. Frontend boundary

- The client is a single-page app with role-specific pages for student, provider, and admin users.

- Shared UI shells, dashboards, and context providers handle auth state, theme, and language; the app is not server-rendered.

4. Identity and role model

- Authentication is JWT-based and role-aware: student, provider, and admin.

- Protected routes on the backend rely on auth middleware; the frontend likely gates navigation using AuthContext.

- Separate registration flows exist for students and providers, with admin accounts created via a script or seed data.

5. Core domain data

- MongoDB collections model the main entities: User, StudentProfile, AidProvider, ScholarshipProgram, Application, Disbursement, Notification, AuditLog, and withdrawal-related records.

- This separation indicates a clean domain boundary between identity, profile data, program data, application workflow, and financial actions.

6. Student intake and document handling

- Student registration includes academic and regional information plus document upload.

- File uploads are handled by multer, and uploaded PDFs are stored locally under backend/uploads, which means document persistence is filesystem-based rather than object storage-based.

7. Program and provider workflow

- Providers can create, update, and close scholarship programs with eligibility criteria and fund allocation.

- The provider-facing pages cover dashboard, program creation, application review, rejected applicants, and provider profile management.

- Program management is a major bounded context separate from student application management.

8. Application review pipeline

- Applications move through an eligibility and ranking pipeline before approval/rejection.

- Services such as eligibility, applicantRanking, financialNeedScore, and duplicateDetection indicate that review is not purely manual; the backend computes decision support and conflict warnings.

- The application route set supports applying, listing personal applications, viewing program applicants, and reviewing submissions.

9. Admin operations

- Admin functionality is broader than CRUD: it includes student verification, at-risk analysis, fraud/rejection review, fund utilization visibility, and report generation.

- The admin dashboard pages mirror these operational concerns and are backed by dedicated admin/analytics controllers.

10. Risk, fraud, and auditability

- The presence of dropoutRisk, duplicateDetection, and auditLog services shows that the system actively evaluates student risk and aid conflicts.

- Audit logging is an important cross-cutting concern, likely triggered by sensitive operations such as approval, disbursement, and verification.

11. Notifications and email

- Notifications are modeled in the database and exposed through a dedicated API.

- Email delivery is handled through utility code and likely uses SMTP via Nodemailer, making notification delivery a side effect of important workflow events.

12. Reporting and analytics

- There is a distinct analytics/reporting slice with regional impact aggregation and report generation.

- Backend report utilities suggest exported formats such as CSV/PDF, which are operational outputs rather than user-facing pages.

13. Main request flow

- Typical flow: user authenticates → frontend stores token and role → API requests hit protected routes → controllers invoke services → Mongoose models persist changes → notifications/audit logs are written as side effects.

- This separation keeps HTTP handling, business rules, and persistence distinct.

14. Operational tooling and deployment

- The repo includes seed/admin scripts for populating development data and creating an admin account.

- render.yaml and vercel.json indicate deployment targets for backend and frontend respectively, reinforcing the split runtime model.