saddamhosen42/mobe

1. Overall shape

- This is a monolithic Laravel 10/11-style application for Outcome Based Education (OBE) grade management.

- It uses server-rendered Blade views, Eloquent models, and traditional HTTP controllers rather than a frontend SPA architecture.

2. Primary runtime boundaries

- Browser/desktop client → Laravel HTTP kernel → middleware → controller → model/database → Blade view

- The app also supports a NativePHP desktop mode, so the same Laravel backend can run as a packaged desktop app in addition to the normal web server.

3. Core domain subsystems

- The repository is organized around academic administration entities:

- Institution structure: faculties, departments, study programs

- Teaching structure: courses, course classes, class settings, class members, portfolios

- OBE curriculum design: intended learning outcomes, course learning outcomes, lesson learning outcomes, learning plans, syllabi

- Assessment and grading: criteria, criteria levels, rubrics, assignments, assignment plans/tasks, student grades, grade details

- User-facing grade views: “my grade” and student grade screens

4. Request handling and enforcement

- Controllers are split by domain and handle CRUD plus specialized flows, for example CourseController, SyllabusController, StudentGradeController, AssignmentPlanController, and MyGradeController.

- Access control is enforced through custom middleware and policies:

- RoleCheck, MustBeTeacher, and ProfileCompleted gate major flows

- policy classes exist for most domain models, so authorization is model-specific rather than purely route-based

5. Authentication and user management

- Authentication follows Laravel’s built-in auth flow with dedicated controllers for login, registration, password reset, email verification, and confirmation.

- User is extended with role/profile-related behavior:

- a role column is added in migrations

- a profile_completed flag controls onboarding/usage

- profile photo storage is supported

- There are dedicated profile screens for different user states, including student-specific profile editing.

6. OBE data model and hierarchy

- The architecture reflects a curriculum hierarchy:

- institution layer: faculty → department → study program

- academic layer: course → course class → class membership

- OBE layer: ILO/CLO/LLO → learning plan/syllabus → criteria/rubrics

- assessment layer: assignments → assignment plans/tasks → student grade records/details

- This suggests the app is designed to propagate curriculum structure into grading and reporting, not just store marks.

7. Persistence and schema evolution

- All core data is persisted in a relational database via Eloquent models and migrations.

- The migration history shows active schema evolution around:

- course/syllabus linkage

- class settings

- student grade redesign

- profile completion and photo support

- cascade-delete fixes across reference tables

- The README’s warning about cascade-delete migrations indicates data integrity across seeded and relationally linked records is important to the system.

8. Presentation layer

- Views are organized per domain under resources/views, with shared layout components and reusable Blade components.

- The app uses standard Laravel layout separation:

- authenticated app layout

- guest/auth layout

- a special create-faculties layout

- Frontend assets are handled through Vite, Tailwind, and a small JS bootstrap layer, so the UI is server-rendered with compiled assets rather than a client-side application state.

9. Background/utility features

- There is a console kernel and seeders for loading real, fake, and Bangladesh OBE sample data.

- Factories exist for most domain models, which supports test data generation and local development.

- Helper functions live in app/helpers.php, suggesting some shared domain formatting or utility logic outside of controllers/models.

10. Storage and external integration

- The app relies on standard Laravel infrastructure: database, filesystem storage, mail/auth/session/cache config.

- storage:link is required, so user-uploaded or generated files are exposed through public storage.

- The presence of public/sw.js and manifest.json indicates some PWA-style assets, but the main architecture remains server-centric.

11. Testing and quality boundaries

- Feature tests cover the auth flow, while the rest of the repo appears to rely on model/controller integration and seeded data.

- Policies, middleware, and migrations are the main architectural guardrails that keep the domain logic consistent across web routes and desktop mode.

12. Diagramming takeaway

- A good architecture diagram should center on one Laravel application boundary with:

- HTTP/UI entry points

- auth/role/profile middleware

- domain controllers and policies

- Eloquent models over a relational database

- Blade rendering back to the client

- Around that core, show the OBE subdomains as distinct but interconnected modules, especially the curriculum/assessment/grading flow.