Can you give a couple of answers about Event Sourcing?

Question

.NET

Hello, I was interested in the Event sourcing model, and as an experiment I threw in a Todo-shku using this approach. I would like you to look at the implementation and possibly suggest how to implement events differently, their mutation, and generally getting the aggregate. I will say right away that I am only interested in the option in one database, but I know about the division into read and write models.
https://github.com/BashkaMen/SimpleEventSourcing-Todo
There are also a couple of specific questions:
1) There is a command and a Todo creation event, let's add something else over time, let's add the description field, I have to modify the creation event or create a creation event 2.0 ? If you create a new one, won't there eventually be a couple of dozen events that exist only to support the old events?
2) If I found a bug that created events incorrectly, what are the options to fix it? After all, events, in theory, cannot be deleted.
3) When I wanted to get all the Todos from the database, I first looked for all the events of the "TodoCreated" type, took their AggregateId and then went to get the aggregates themselves, is this the right approach?

Answer 1

1) is solved in different ways, ideally - all created events are non-mutable and lie in the database forever. This avoids a lot of problems. That is, when changing, you need to create an event v2. But - this is only for incompatible changes, adding a field can usually be made compatible. The code that will work with this field will work should take into account that description may or may not. The old code that worked without description will work as it did and will remain unchanged.
Most often it is enough to add new events for new things. For example, there used to be aggregates without description, now this field has appeared, which means that some operations have appeared on this field and you can add the DescriptionAdded event instead of changing the creation event.
However, I've seen articles about people rewriting the history of events to support the new format - maybe in some cases this is really more optimal. I did not, I do not know the pitfalls.
2) create "correcting" events. for example, your bug added an extra day to everyone's birthday when creating users - create more events that take away this day.
3) It depends on the implementation of the store, but to read all the events from the store in order to filter them in memory, in any case, the approach is so-so. A real application with this approach will be bent extremely quickly.
Projections are used for such things - when you build the desired model from events in some convenient form and make requests there.
for example, store in SQL the todo list for the current moment, with all the events, and just do select * from todo.
well, or at least make a table with all create events to read not 50 million and filter, but immediately get a list of aggregates with one request.
This is where eventual consistency comes into play.