📋 Visit Tracking

Overview

A domain-driven visit tracking system with four distinct role levels. Teachers log support requests, ICT staff record visit details and resolutions, admins oversee department-wide activity, and system admins manage configuration. Authentication is handled via NextAuth with Google OAuth.

Key Features

• Role-based dashboards — Separate views and capabilities for Teacher, ICT Staff, Admin, and SystemAdmin roles, enforced through the shared mc-rbac package
• Visit logging and resolution tracking — Structured records for each visit including reason, actions taken, and resolution status
• CSV export — Dedicated endpoint for exporting visit data to CSV for reporting
• Health check endpoint — Operational health check for monitoring in production

Architecture

Follows a domain-driven design with explicit layers: /domain contains entities and value objects, /infrastructure handles persistence and external services, and /application provides use-case orchestration. This separation keeps business rules framework-independent and independently testable.

Testing

• Vitest unit tests covering domain logic
• Playwright E2E tests for critical user flows
• Stryker mutation testing targeting src/domain/**/*.ts with enforced score thresholds
• Lighthouse CI for performance and accessibility regression checks

Design Decisions

• Domain-driven design: Visit tracking has real business rules — visit lifecycle states, role-dependent workflows, resolution tracking, CSV reporting. These are domain concepts that would otherwise scatter across API routes, React components, and middleware. Once the logic is complex enough that a change to “how visit resolution works” would touch multiple files, extracting a domain layer keeps the rules testable in isolation and the Next.js layer thin. Simpler apps in the monorepo (Interactive Guides, Printables) are mostly content delivery, so a flat structure is fine there.
• Four role levels: Maps directly to the school’s organisational structure. Teachers log that ICT visited their room. ICT staff record what they did. A head of department needs oversight across all visits for reporting. A SystemAdmin manages configuration and role assignments. In NSW schools the ICT department typically has this hierarchy, especially at a college with enough scale to need dedicated tracking.

Demo

Visit tracking: logging support visits with role-based views and resolution tracking.