Domains Overview
The map of every functional area in the platform, and the rule that decides what lives in core vs. an EMA.
The backend is organized into domains — folders under
apps/backend/src/modules/, each mapping to a slice of the core database. This
page is the map; the following pages drill into the most important ones.
The rule: core vs. EMA
Before the map, the rule that governs it (ADR-003):
Core holds institution-agnostic interaction channels. Everything domain-specific is an EMA.
- Core = feed, messaging, tasks, timeline, notifications, organizations. These are the same whether you're a daycare or a high school.
- EMA = attendance, gradebooks, behavior tracking, library, transport, parent dashboards… anything specific to a kind of institution.
This keeps the core small and lets different institution types run on the same foundation with different EMA sets. See The EMA ecosystem.
Some domains below (e.g. academic) exist in the backend today even though, by ADR-003, much of that surface is intended to be delivered through EMAs over time. When in doubt about where a new feature belongs, default to an EMA.
The domain map
| Domain | Key sub-modules | What it covers |
|---|---|---|
| core | feed, messaging, tasks, timeline, organizations, user-reports | Daily interaction channels. → details |
| academic | students, teachers, courses, grades, attendance, enrollments, OneRoster | Student-information-system operations. → details |
| student-life | achievements, behaviour, clubs, career, health-records | The non-academic student experience. |
| family | children, members, pickup, consent, passport | Guardian relationships + the development passport. → details |
| people | profiles, onboarding, roles, directory, groups | Member management within an org. |
| communication | announcements, broadcast, templates | Bulk/orchestrated messaging on top of core channels. |
| notifications | channels, digest, in-app, push | Delivery of events to users. |
| productivity | automations, mindmaps, canvas, lesson-planner | Individual/team authoring tools. |
| time-management | appointments, shifts, timesheets, leave, check-in | Scheduling and staff attendance. |
| finance | billing, payments, invoices, scholarships, accounting | Money flow. |
| asset-management | facilities, assets, library, dormitory, transport | Physical resources. |
| security / health / support | guest-book, clinic, cafeteria… | Operational safety, health, and catering. |
| content | changelog, blog, subscribers | Platform content. |
| platform | apps, api-keys, webhooks, app-builds, feature-flags | The EMA ecosystem and ops. → details |
| legal | documents, consents | KVKK/GDPR consent and agreements. |
| audit | partitioned event log | Immutable who-did-what-when. |
| intelligence | ai-insights, ai-query-logs | AI insights (conditionally enabled). |
How a domain is shaped
Every domain follows the same internal skeleton, so once you've read one you can navigate any of them:
modules/<domain>/<feature>/
├── <feature>.module.ts wiring
├── <feature>.controller.ts routes + DTO validation + @RequirePermission
├── <feature>.service.ts business logic
├── <feature>.repository.ts extends OrgScopedRepository
└── dto/ request/response DTOsTenant scoping, ID generation, side effects, and validation all follow the platform-wide conventions described in Backend and API conventions.