That use case is compelling! If you have time to try, you could follow the development process like in the book:
a) Write the logic for use cases like rating, querying averages and so on in pure Elixir
b) Try storing the results in the GenServer for each teacher (similarly to having one game process)
c) Figure out in the end what do you want form the storage.
I assume you would want to do some aggregation in the end. How many votes there were, who was the best teacher and having three entities (student, teacher and score) begs for a relational database.
The point of DDD is not “do not use relational database”. It is “do not pollute your logic with DB details”. E.g. your code might model a teacher as a struct that has a list of scores. It is pure Elixir model, and your application logic does not care if it uses left join or right join or stores the scores as JSONB or whatever else you think is optimal.
An added benefit of starting with the in-memory model is more interactivity. Maybe you could send a push notification to a teacher when his score drops below three stars?
Starting from the database makes you think on the wrong level. E.g. you will need some authorisation and authentication both for teachers and students. If you start from the database, you immediately think: “should I create another users table and have foreign keys in teachers and students tables? Maybe teachers and students should be in one table and have a role field?”.
Starting from the use case, you create a struct called User or Account, implement the feature and defer retrieving the users for later. Maybe you’ll end up with getting users from LDAP or private school students database, and you won’t have to persist them at all?
In general, I disagree with the author of “Doing without database…”. DBs are there. They solve problems almost everyone has. Let’s use them. I agree with DDD approach of not caring about DB as long as possible.
Developers sometimes say stuff like: “you should abstract the database! what if you need to change it?” That happens so rarely that I would dismiss it. Abstracting database away has other benefits: your business logic gets simpler and easier to test in isolation. In case, you do a big migration, you’ve decoupled code that performs business from the code that loads stuff, and you can change only the latter without touching “business layer”.
TL;DR DDD=good stuff; NO_DB movement=meh
)