# Mit Jesperhus BFF architecture

## Boundary

The mobile apps consume stable DTOs from this BFF. They do not depend on booking-provider, programme-provider, weather-provider, database, or push-provider models. The backend is one modular ASP.NET Core monolith and one deployment unit.

Booking is intentionally outside V1 delivery until Jesperhus supplies integration details. A manual stay is a first-class stay, not a fake reservation. Future booking adapters must map into the same normalized stay model.

## Modules

- Catalogue: verified places, accommodation types, content, media references, aliases, and provenance.
- Programme: event definitions, dated occurrences, Danish-local date queries, and Now/Next rules.
- Home: a mobile-oriented aggregate of stay context, programme, itinerary, and operational messages.
- Installations: anonymous app identity and credential lifecycle.
- Stays: privacy-minimized manual stay data and future reservation-provider boundary.
- Favorites and itinerary: installation-scoped personalization with distinct semantics.
- Devices and notifications: push registration, preferences, reminders, durable delivery, and invalid-token handling.
- Operations: temporary messages, closures, changes, and audience validity.
- Administration: protected mutations and audit records.

## Time and identity

- Instants are persisted in UTC and returned with ISO-8601 offsets.
- Jesperhus business dates are interpreted in `Europe/Copenhagen`.
- Installation IDs are identifiers, not credentials. Personalized calls require the installation credential issued once at registration; only its hash is persisted.
- Child names and birth dates are not required. Child ages are sufficient for V1 personalization.

## Persistence

Development and fast integration tests may use SQLite. Production uses SQL Server when the selected Simply.com ASP plan supplies MSSQL. The provider is selected by configuration. Database migrations are applied explicitly during deployment and not automatically on every IIS startup.

## Background work

IIS application pools may sleep or recycle, so scheduled reminders are persisted and never depend on a continuously running in-process worker. A scheduler invokes a protected, bounded job endpoint. Jobs use leases, retry metadata, and unique idempotency keys.

## Content truth

The existing source-attributed official Jesperhus catalogue is the initial static source. Missing schedules, prices, availability, opening times, accessibility facts, and booking data remain unknown. Development-only examples must be explicitly marked and never become production facts.