School canteen management with allergy tracking

Problem

A school canteen handles data that cannot be wrong: which child has which allergy, and what to do if something happens. When that lives in spreadsheets and printed lists, information duplicates, goes stale, and nobody knows which copy is current.

Solution

An API organised by domain, each module self-contained: model, persistence configuration, repository and controller. Students, allergies and their relationship are first-class entities, so an allergy is defined once and associated, rather than retyped on every record.

Every entity inherits auditing and soft delete, because in this domain you want to know who changed what and be able to recover a record retired by mistake.

Architecture

Technical decisions

• Domain modules instead of folders by technical type: allergy code lives together, not spread across four directories.
• EF Core configurations split per entity, outside the context.
• A base entity carrying auditing and soft delete, inherited across the model.
• Server Components on the front end, with session state resolved server-side.

Result

Modular backend covering users, students and allergies, with a Next.js front end consuming the API. Still evolving: students and allergies are modelled and pending completion of their exposure layer.