Skip to main content

System Overview

Purpose​

This document provides a high-level overview of the Chilarai platform architecture.

It defines:

  • System purpose
  • Business capabilities
  • Core actors
  • Architectural principles
  • Major system components
  • Bounded contexts
  • High-level data flow

This document intentionally avoids implementation details.

Implementation-specific decisions are documented in subsequent architecture documents.

Vision

Chilarai is a multi-tenant School Management Platform designed to manage academic, administrative, operational, and financial activities for educational institutions.

The platform provides a unified experience for:

  • School Administrators
  • Teachers
  • Parents
  • Office Staff
  • Finance Staff
  • Platform Administrators

The platform supports the complete student lifecycle from admission to graduation.

Goals

The primary goals of the platform are:

  • Simplify school operations
  • Improve administrative efficiency
  • Centralize school data
  • Enable digital-first workflows
  • Support future student and parent experiences
  • Provide a scalable multi-tenant SaaS platform

Core Principles

Multi-Tenant Platform​

Each School operates independently within the platform.

Data, users, and operations are isolated at the School level.

School-Centric Design​

The School is the primary business entity.

All business operations occur within the context of a School.

Examples:

  • Admissions
  • Attendance
  • Assessments
  • Fees
  • Student Management

Identity and Business Separation​

Authentication and identity management are separated from business operations.

Identity is managed through:

  • Keycloak
  • User
  • School Membership

Business operations are managed through domain entities.

Examples:

  • Student
  • Admission
  • Attendance
  • Assessment
  • Fees

Configuration Over Customization​

Schools configure behavior through data and configuration.

The platform avoids school-specific code whenever possible.

Event-Aware Architecture​

Operational events are treated as first-class concepts.

Examples:

  • Attendance Events
  • Payment Events
  • Admission Events

Business records may be derived from events.

Actors

Platform Administrator​

Responsible for:

  • School Onboarding
  • Subscription Management
  • Platform Configuration
  • Platform Governance

School Administrator​

Responsible for:

  • School Configuration
  • User Management
  • Academic Configuration
  • Admissions
  • Staff Management

Teacher​

Responsible for:

  • Attendance
  • Assessments
  • Student Progress

Parent​

Responsible for:

  • Student Monitoring
  • Admission Requests
  • Fee Payments

Staff​

Examples:

  • Receptionist
  • Accountant
  • Office Administrator

Responsible for operational activities within the School.

Business Capabilities

The platform consists of the following major business capabilities.

Identity Management​

Provides:

  • Authentication
  • User Management
  • Membership Management
  • Authorization

Core Domains:

  • User
  • School Membership

School Administration​

Provides:

  • School Setup
  • Academic Year Management
  • Academic Structure Management

Core Domains:

  • School
  • Academic Year
  • Academic Structure

Student Management​

Provides:

  • Admissions
  • Student Records
  • Student Enrollment

Core Domains:

  • Admission
  • Student
  • Student Enrollment

Academic Management​

Provides:

  • Subjects
  • Class Assignments
  • Teacher Assignments
  • Assessments

Core Domains:

  • Academic Structure
  • Academic Assignment
  • Assessment

Attendance Management​

Provides:

  • Attendance Recording
  • Attendance Processing
  • Attendance Event Capture

Core Domains:

  • Attendance
  • Attendance Event

Staff Management​

Provides:

  • Employee Records
  • Designations
  • Academic Responsibilities

Core Domains:

  • Staff

Financial Management​

Provides:

  • Fee Structures
  • Student Billing
  • Payments
  • Discounts
  • Late Fee Processing

Core Domains:

  • Fees

Bounded Contexts

The system is organized into the following bounded contexts.

Identity Context​

Responsibilities:

  • Authentication
  • User Management
  • Memberships
  • Roles

Domains:

  • User
  • School Membership

School Context​

Responsibilities:

  • School Configuration
  • Academic Years

Domains:

  • School
  • Academic Year

Academic Context​

Responsibilities:

  • Classes
  • Sections
  • Subjects
  • Academic Assignments
  • Assessments

Domains:

  • Academic Structure
  • Academic Assignment
  • Assessment

Student Context​

Responsibilities:

  • Admissions
  • Student Lifecycle
  • Enrollment

Domains:

  • Admission
  • Student
  • Student Enrollment

Attendance Context​

Responsibilities:

  • Attendance Events
  • Attendance Records

Domains:

  • Attendance

Staff Context​

Responsibilities:

  • Employee Management

Domains:

  • Staff

Finance Context​

Responsibilities:

  • Fee Configuration
  • Student Billing
  • Payments

Domains:

  • Fees

High-Level Architecture

Users
    │
    ▼
Web Application
    │
    ▼
Application Services
    │
    ├── Identity Context
    ├── School Context
    ├── Student Context
    ├── Academic Context
    ├── Attendance Context
    ├── Staff Context
    └── Finance Context
    │
    ▼
Data Platform

Core Domain Relationships

School
│
├── Academic Year
│
├── User
│    └── School Membership
│
├── Staff
│
├── Admission
│
├── Student
│     └── Student Enrollment
│
├── Academic Structure
│     ├── Class
│     ├── Section
│     └── Subject
│
├── Academic Assignment
│
├── Attendance
│
├── Assessment
│
└── Fees

Cross-Cutting Concerns

The following concerns apply across all bounded contexts.

Authentication​

Managed by the Identity Context.

Authorization​

Role-based access through School Memberships.

Auditing​

All business entities support audit tracking.

Examples:

  • CreatedBy
  • CreatedAt
  • UpdatedBy
  • UpdatedAt

File Storage​

Documents and media are stored outside the transactional database.

Examples:

  • Admission Documents
  • Student Photos

Notifications​

Notification delivery is treated as a cross-cutting capability.

Examples:

  • Admission Updates
  • Attendance Notifications
  • Fee Reminders

Future Expansion

The platform is designed to support future modules including:

  • Student Portal
  • Parent Portal
  • Transport Management
  • Library Management
  • Timetable Management
  • Academic Calendar
  • Hostel Management
  • Report Cards
  • Analytics and Reporting

These capabilities should be added without fundamental redesign of the existing architecture.

Summary

Key architectural decisions:

  • School is the primary business entity.
  • The platform is multi-tenant.
  • Identity is separated from business operations.
  • Business capabilities are organized into bounded contexts.
  • Attendance is event-aware.
  • Finance is configuration-driven.
  • Academic structure is reusable across years.
  • Student lifecycle is managed through admissions and enrollments.
  • Future expansion is supported through modular bounded contexts.