ReadModel

[jaduff]

Does the read model have to worry about pending events? RoomContext.cs has: public List<ILabEvent> ReceivedEvents { get; } = new List<ILabEvent>(); public List<ILabEvent> PendingEvents { get; } = new List<ILabEvent>();

But the ReadRoomContext.cs (as I'm going to call it) will presumably need only the events as retrieved from the database? Or is there some idea of saving state outside of the database? Will data persist in memory, using the database only as permanent storage?

[jaduff]

Your diagram would suggest not, the queue is a long way before the data storage of the read model.

[simonjduff]

You'll only need one collection, that is the collection of events to replay into the read model. The write model needs two, because it replays to internal state, and then raises new events when actions are performed.

[jaduff]

So for a particular room, the contents of the database matching the room's unique ID would be pulled into a list of LabEvents of varying types. Each event would be assessed one at a time in order of version, The EventType of each event would be used to manipulate an object of class Room, with additional details being supplied from the EventBody. Once all events have been assessed and processed, the object of class Room should be an accurate representation of the state according to the database at the time the data was retrieved. This data can then be displayed to the user. Even if its not current, any action taken by the user would be re-assessed against more current data by the write model, and an error thrown back to the user if there is a problem that cannot be resolved.

Am I on the right track here?

[simonjduff]

Yeah that's about it. In a more mature solution, we wouldn't load all the events to present to the user, we'd have stored a version ready to be viewed, which we then update each time an event is raised. This requires a message bus and a queue processor or something, which is not needed at your scale