Kurse und Lernzugänge

Learning management system domain modeling

When to use

When implementing or reviewing an LMS course lifecycle, enrolment flow, cohort model or learner access boundary. Establish these invariants before choosing tables, APIs or screens.

Delivering a complete learning product

For a whole-system request, establish audience, subject, language, course scope, sale model, completion/certificate policy and hosting constraints. Inspect the repository; for a new product choose the smallest supported stack. Record missing policy decisions and continue independent work.

Split the journey into tasks with owners, acceptance evidence and required skill names:

• Actual lessons, exercises and assessment content: learning-content-production.
• Verified purchase to course access and later refunds/expiry: lms-commerce-enrolment, with the available billing specialist covering provider mechanics.
• Attempts, grading, progress and downloadable/verifiable certificates: learning-progress-assessment.
• Access boundaries: authorization-verification; learner/author interfaces: web-accessibility.
• External learning standards only if required: learning-interoperability; remote adapters: api-integration.

Check the skills actually loaded. For missing or truncated guidance, split the task or request it through the existing workflow. Assign available frontend, backend, testing and operations capabilities as needed.

Exercise authored-content publication → verified purchase → enrolment → lesson/resume → failed/permitted exam retry → completion → certificate download/verification. Include wrong-user access, duplicate payment delivery and certificate revocation. Hand over evidence, unfinished scope, configuration, asset storage, recovery and observed deployment state. A demo or local test does not establish a complete course or production release.

Workflow

1. Inspect platform/plugin versions, schema, authorization and course data. Identify the owners of learner identity, enrolment and assessments. Use anonymized examples and release-matched documentation; do not assume an installed plugin supports the latest API.
2. Separate the domain objects and their identifiers:
   • A course is the stable offering; a course version fixes published lessons and requirements.
   • A lesson/activity belongs to that version. An attempt captures one learner's submission against an activity and assessment version.
   • Progress records observed activity. Completion applies policy to required evidence. A certificate separately references that completion and policy version.
   • Enrolment connects a learner to a course, cohort or offering with an effective period and status. A role grants contextual capabilities; a global role alone does not establish course access.
3. Model draft/published/archive, invited/active/suspended/ended enrolment, transfer and renewal. Name actor, preconditions, effective time and preserved history. Progress writes cannot reactivate suspended enrolment.
4. Authorize organization, course, enrolment state and capability on the server for content, downloads, assessments, grades, exports and jobs. Teaching access is separate from enrolment: teaching one course grants no access to another course or organization's learners.
5. Choose version continuity: keep assigned versions, migrate with an explicit mapping, or restart specified requirements. Preserve attempts, grades and certificates; never silently reinterpret historical completion against today's course structure.
6. Reuse persistence and policy patterns. Before authorized migrations, preview affected enrolments, mappings, invalid references and recovery steps. Do not reset a database to simplify migration.

Evidence and verification

Deliver entity ownership, transitions and a course-access matrix grounded in code and records. Include two enrolments for one learner, suspension, a cross-course instructor and a course updated after an attempt.

Verify that unauthorized course IDs cannot expose content or grades; unenrolment does not erase historical evidence; re-enrolment follows the stated continuity policy; and concurrent enrolment requests do not produce inconsistent active records. Distinguish a passing local fixture from behavior verified in the installed LMS.

Boundaries

• Have the learning owner define required activities, passing rules, equivalencies and certificate eligibility. Do not invent these policies or treat a page visit as proof of learning.
• Keep learner support and accessibility needs separate from unrestricted course rosters. Expose only the accommodation information needed by authorized teaching staff.
• Preserve historical records and tenant boundaries. Destructive data changes require explicit human authorization naming the environment, target and purpose.

Primary reference

Use the matching release documentation and inspect local extensions before applying platform-specific behavior:

• https://moodledev.io/docs/5.0/apis/subsystems/enrol