rajappan47/jobportal_backend

Purpose and runtime

This is a Django-based applicant tracking system (ATS) backend. It organizes recruitment data around accounts, companies, jobs, candidates, and job applications, with an AI-oriented service layer. The project can run through Django’s development/management entry point at manage.py, or deploy through WSGI/ASGI via ats_backend/wsgi.py and ats_backend/asgi.py.

Project composition and routing

ats_backend is the composition root: settings and top-level URL routing are in ats_backend/settings.py and ats_backend/urls.py. Feature apps expose their own route modules—such as accounts/urls.py, jobs/urls.py, and applications/urls.py—which are expected to be mounted by the root URL configuration. This keeps HTTP API ownership aligned with business domains.

Identity and account boundary

The accounts app owns user/account persistence, API serialization, and request handlers:

• accounts/models.py

• accounts/serializers.py

• accounts/views.py

Its migrations include a custom-user-related evolution (accounts/migrations/0002_alter_user_options_alter_user_managers_and_more.py), indicating that identity is a foundational cross-domain dependency. Other domain records should reference this account model rather than introducing independent user identity.

Recruitment domain model

Company and job data are separated into dedicated bounded areas:

• Company lifecycle/API: companies/models.py, companies/serializers.py, companies/views.py

• Job lifecycle/API: jobs/models.py, jobs/serializers.py, jobs/views.py

Job schema evolution includes deadline, type, and location fields (jobs/migrations/0002_job_deadline.py, jobs/migrations/0003_job_job_type_job_location.py), making a job posting the likely central entity for recruiting workflows.

Candidate and application workflow

Candidate profile data is managed independently from applications:

• candidates/models.py

• candidates/serializers.py

• candidates/views.py

Applications form the association between candidates and jobs, with their own persistence and API boundary:

• applications/models.py

• applications/serializers.py

• applications/views.py

The application migration applications/migrations/0002_alter_application_unique_together.py indicates an explicit uniqueness constraint, likely protecting against duplicate candidate/job submissions. The core flow is therefore: account/profile and company setup → job creation → candidate profile/resume → application submission and tracking.

AI integration boundary

AI functionality is isolated from core CRUD apps:

• ai_engine/services.py

• ai_engine/views.py

Views provide the HTTP-facing integration point, while services should contain provider calls, document analysis, scoring, or matching logic. This separation is important: AI processing can consume candidate resumes and job/application data without embedding external-service concerns into domain models or serializers.

Persistence and file storage

Django migrations define the relational schema across all business apps, while the checked-in development database is db.sqlite3. Resume and application documents are stored as media files under:

• media/resumes

• media/applications

This creates a material boundary between relational metadata in application/candidate models and file-backed resume artifacts. Production deployment should account for durable media storage and database replacement/management, as SQLite and local media paths are development-oriented infrastructure.