The code can be found here

Though I'm fairly familiar with the tech stack I used here, I took it as a personal challenge to use the latest tech versions, utilize new features when possible, and get to the best possible result. The test is written in .NET Core 3.1, ASP.NET Core 3.1 (MVC), Entity Framework Core 3.1, AutoMapper, Angular (latest), Bootsrap, Moq, FluentAssersions and more.

A few points about the test:

1. The API was fully written in TDD (as you can see to some extent in the commits). The guiding thought was not "how will I test this?", but "how do I write code which passes this test?". Notes: The controllers were written as implemented UnitTests. The services (and the used repository) were written as implemented Integration Tests using the EF Core 3.1 In-Memory DB I wanted to do the UI in TDD as well but didn't. I'll explain why when we review this.
2. I have not used my own Testing framework here... Ask me why ^_^
3. The code was divided in one of the many interpretations of DDD
   Side note:
   There are various ways to organize the code called in a way that it is called DDD. In fact, any way that allows the Domain to be independent from the model, and subsequently everything else, can be called DDD. Each company/team/project have their own way of organizing their code (and call it DDD), just like different interpretations of agile and scrum are used. As long the structure serves its purposes, I don't think it is not "incorrect".

   The reason I'm taking 5 sentences to elaborate on this, is because I know many times it seems like one way is right and another is wrong, and I don't want this structure to be "my" structure, it is what I found fitting for use here.

4. The domain models are not separate in this case. I know some like to take it to it's own "contracts" project, but I did not do that here.
5. All the DB definitions are in the DbContext and not in the objects, in order to not "contaminate" them.
6. I've used a set of separate DB model objects, even though I could have used the domain objects to show a clear-cut separation.
7. Though many may consider the "Repository" layer as no longer needed, I believe it does make it easier if/when other DB are used (Cache/Redit/Whatever), and could even make it easier to move to Event-Based architecture in the future.
8. All tests were written asynchronously and are designed to be independent and to run in parallel.
9. Angular - I did my best... Not really a front-end expert :)

Please ask me about these decisions... I will hopefully have good explanations for everything I did.