Code review. Console application for creating and passing quizzes. C#?

Question

code review

I'm learning C#, OOP principles.
For the purposes of practice, I wrote a simple console application Quiz.

Link to the repository: https://github.com/juliion/Quiz

Who is not difficult, please write an opinion about the code, architecture.

Answer 1

1. It is not clear why I used the old .net framework
2. Why does Score have public getters-setters, if in theory the class is immutable and it even has a constructor with required parameters?
3. Everywhere there is a link to the Russian language, which is not very good, but not fatal either.
4. There is a small problem with method naming, but not critical
5. Standard binary serialization is evil almost always.
6. Passwords are in open form, and there is not even any abstraction over the data storage format (if there was an abstraction, it would not be so critical)
7. Relative paths (found in Manager.cs). By themselves, relative paths are not bad, but here they are already knocking on the parent folder.
8. It is not clear why there are only three hardcoded types of quizzes. I did not see the difference between them in the code.
9. Main menu in a procedural style with completely non-speaking names of methods and constants - well, this is completely out of the question.
10. I like that there is immediately a division into two bounded contexts - passing quizzes and creating. In principle, it will not be difficult to refactor.
I won't check further. It seems that the author simply did not work out the subject area enough and did not work out the application architecture based on this.
I advise you to read books:
"Clean Architecture" by Robert Martin
"Object-Oriented Design (DDD). Structuring Complex Software Systems" by Eric Evans
It doesn't have to be the whole book - you can just read articles and watch reports about how to build an application architecture.
In short:
1. Try not to mix domain model and implementation details
2. If you make rich models (with methods that reflect the essence of the domain), then use them everywhere.
3. If you make anemic models - make them everywhere. You should not mix both approaches within the same context
4. Ideally, the code should look so that it is immediately clear what is happening and why. It should also be obvious where and what to look for.
5. In an ideal world, the code should be such that if you were given the task of "transferring it all to the web", you would not have to change the core code at all (in this case, the QuizModel project), and at the same time you would not have to duplicate the code from QuizCreator and QuizApp