System design of our educational platform

Let's go through our initial system design of an educational platform we will be creating together!

Overview

So in the previous episode of our EduTaskHub series, I showed you how to create an initial CI/CD pipeline to get a skeleton application up and running.

I realise a fatal error on my part. I didn’t discuss the system design! I sketched it out, but realise I didn’t communicate that with anyone. But how can we build something together, if you don’t know what we’re building and how?

A common misconception with agile is that no design is done, that’s simply not true. I think this comes from the following statement in the agile manifesto:

Working software over comprehensive documents.

But what they fail to recognise is this section within the history page:

We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.

Which aligns with what I believe that documentation is still an important part, but we want to minimise over-documentation.

Requirements

EduTaskHub is an open-source educational platform designed to simplify the process of distributing and marking assignments for students and teachers. This platform aims to improve the efficiency of assignment management and enhance collaboration within an educational environment.

We have to accommodate the following features:

• Courses:

  • Teachers can create courses, add other teachers as co-owners and assign students to those courses

  • Courses can have multiple lessons, which can be ordered

  • Assignments:

    • Teachers can create and distribute assignments to students

    • Assignments can include detailed instructions

  • Submissions:

    • Teachers are able to review and mark student submissions quickly

    • Students can submit submissions for their assignments

• Notifications:

  • Ability to turn notifications on/off:

    • When teacher’s add/edit/delete an assignment

    • When a student’s submission is due

    • When a student uploads a submission

    • When a student’s submission has been graded

• Payments:

  • Courses can be free or paid

  • Paid courses need to be taken to payment flow before enrolling

  • Free courses need can bypass this payment flow

  • Paid courses can have special codes or discounts

These are some high level requirements per role:

Yes, I’ve completely fabricated these requirements (but just play along with me) as they give us a starting point.

Initial Design

It’s clear to me the core functionality resides with the course/assignment/submission flow, and so this will be our starting point.

With these requirements in mind, our initial approach will be to implement a clean architecture, with a domain driven design approach where we have the following layers:

1. Domain

2. Application

3. Infrastructure

4. Presentation

In the future we might also want to add other domains such as the following, to allow for the ability to manage notifications and the ability to accept payments for courses.:

For our presentation layer, there are two architectures I’m considering:

1. Blazor Server → Application Layer + Third Party API → Application Layer

   

2. Blazor Server → API → Application Layer

   

The controllers that are connecting to our application layer will be very lightweight, and thus I’m not sure if it is necessary for an additional API layer between the Blazor server and application layer.

However, it would allow for additional capabilities in the future, for example, if we ever needed to connect to the endpoints without using the frontend. I could always just add a third party API to account for any endpoints that need to be done this way if this became a requirement.

What are your thoughts?

External Services

There are various external services we need in order for our system to work, I will be predominantly using Azure for my services, but there should be like-for-like alternatives for anyone wanting to use other cloud providers.

1. Authorisation and Authentication: Azure AD, I will have the following roles configured on the app registration: Teacher, Student and Administrator.

2. Database: Azure SQL will be used for the database, I will also be using SQL Server locally as the are, for the most part, compatible and interchangeable.

3. Logging: Application Insights which will monitor users interactions and flows, and I will also use Serilog for structuring logs that come from the application.

4. Email: Azure SendGrid will allow us to send emails from our application to users in the system.

5. Pipeline: GitHub Actions will be used as our continuous integration and continuous deployment pipeline.

6. Hosting: Azure App Service, we will be initially using this for our application, but if we decide to implement an API, we may look to use Container Apps in the future.

Next Steps…

So we’ve now got our initial scope, we still need to do some database design and requirements breakdown, which we will do next time! Then, we should have enough to get started with building our application!

We still need to answer the following questions:

1. What is the best way to synchronise users between Azure AD and our database? Our teachers want to be able to add students to their courses before they do their initial log in.

2. Should we let our third party provider handle our authorisation and only deal with the claims? Or should we add roles and permissions in our database?

3. Should we have blazor server → application layer? or should we have blazor server → api → application layer?

4. Should the authentication and authorisation be handled in the presentation layer or infrastructure layer?

What are your thoughts? Let me know in the comments below!

Hear more on my YouTube Video where I go into this in more detail: