ADR 0002 — Five Stitch modules as bounded contexts
Status: accepted
Date: 2026-09-19
Context
AFIA-resources/design.txt lists five Google Stitch projects. The public landing names four (Patient, Médecin, Imagerie, Laboratoire). Admin exists only in Stitch. Screen UIs were not readable in this session (Google login). We still need a cut that implementation will not have to unwind.
Decision
Treat each Stitch project as a bounded context, not as a deployable and not as a Flutter package named after a screen.
| Stitch module | Context | Owns |
|---|---|---|
| Patient | patient | Patient profile, patient-initiated booking, patient-visible results |
| Médecin | clinician | Clinician profile, agenda, encounter notes |
| Admin | admin | Users, roles, clinics, configuration |
| Imagerie | diagnostics (kind=IMAGING) | Imaging orders, worklist, reports |
| Laboratoire | diagnostics (kind=LAB) | Lab orders, worklist, reports |
Join types (shared language, not a sixth Stitch module): Account, Appointment, Encounter, DiagnosticOrder, DiagnosticResult, Consent.
Imaging and lab share one model. Different worklist UIs later do not split the API.
Do not invent screen lists. After a Stitch export, add a new ADR (next free number, via WP-10) with a screen-to-context map.
Consequences
- Five Stitch files do not become five microservices or five store apps.
- Admin can stay off the public landing cards. The client is still an
afia-approle shell. See ADR 0007. - Health data (results, notes) is owned by
diagnostics/clinicianand only projected to the patient.