How to model complex event in event sourcing?

Question

Lets say that we have a user (like super-hero) that want to see all wars that is going on in a world so that he can stop them. He can't prevent them all, because he needs to sleep sometimes and so on. But if a war have happened when he was asleep, he wants to know about that (so he can punish ones who started it for example).

So if war started he wants to see where it have happened and when. And also all events about this war, like some battles for example.

So he wants software that can present him this information at some 'war table' where he can see all wars that he still haven't reacted to in some way.

And that's a software that I need to write.

So lets say that I have some software that monitors some state and based on lower level events generates events like 'War started', 'War ended', 'Battle started', 'Battle ended', 'War changed location' etc.

The problem that puzzles me is that at the time when War started - war is a process, not an event. Because war is still going on. But after the 'War ended' event we can say that this process in ended and now it is a event.

To be more concrete. Lets say that the sequence of events is:

'War1 started at location x1' 'War2 started at location x2' 'War1 changed location to x4' 'War2 changed location to x5' 'War1 have a new battle started at location x3' 'War1 have a new battle ended at location x3' 'War1 ended'

But the user doesn't want to see this as a sequence. What he wants to see is something like this

'War1 is going on at location x1' 'War2 is going on at location x2'

Then he wants the first row to change according to next event

'War1 is going on at location x4' 'War2 is going on at location x2'

and so on

'War1 is going on at location x4' 'War2 is going on at location x5'

and so on until this wars would end.

'War1 was at location 'some location'' 'War2 was at location 'some different location''

As you can see war1 and war2 is events now.

After war is ended super-hero still want to know all information about it if he want to, but in this war-table he basically wants to see current information about war process.

Right now the solution is to think about this war process as process, that can be still going or have been already ended. The problem is that in this case if we would want to monitor some event that is different then war and more simple (like it some switch that can be just on or off) we would have model that as a process that have a start time and stop time. Which is... strange I think.

I thought about different solution. Instead of displaying processes display lower level events grouped by subject.

Like 'War 1 have started' and 'War 1 have ended' have the same subject - 'War 1' process.

But not all events in our system would have process as a subject and... I'm kink of lost here.

Maybe someone already have done something like that? What could be the correct approach to that?

Answer 1

I have several thoughts on your question.

---

What your talking about is done in a larger context with patterns like CQRS (Command Query Responsibility Separation) and Event Sourcing, and the "lambda architecture".

These architectural patterns address scale, fault tolerance/recovery. Essentially Event Sourcing captures and persists events in the system as append-only log structure, some process reads the logs and feeds to a database of some sort that maintains the current state translating each event into an update of the database; fault tolerance and recovery from the database crash are accomplished by re-reading the event log. Other parts of the architecture maintain different representations of the current state, one might be write-optimized (normalized) another read-optimized (denormalized as per application queries).

While these patterns are probably applied at scale larger than you are attempting, the idea behind them is similar -- to translate between different representations, which start with events and go toward current state (in several representations for different purposes).

---

On another note, I would say that an event is associated with a time (when the event occured), and a process with a start time and end time. Some processes are ongoing, but all that means is that we don't know their end time (yet). Just because a process ends (i.e we learn their end time) doesn't convert it to an event, it is still a process.

---

You should definitely try to have a "subject" of your messages. That will help translating events to current state. In my opinion, information modeling should attempt to capture and represent facts. Facts can be represented by sentences, in one simple example, by subject, verb, object. These patterns help a lot when trying to capture and translate meanings between different forms (i.e. events and current state)

Maybe you could give an example of an event that doesn't have a subject, and we could discuss.

Answer 2

In event sourcing, the events typically represent the history of one or more entities (ie, a thing/noun that has identity, and state that changes over time). To recreate the state of an object, you replay its history.

So this is the right idea:

I thought about different solution. Instead of displaying processes display lower level events grouped by subject.

Like 'War 1 have started' and 'War 1 have ended' have the same subject - 'War 1' process.

Replace "subject" with "unique identifier" and you've got the right idea -- all of the events that describe the history of War 1 have the same identifier, and can be used to assemble a projection (view) of what that war looks like at any point in history.

So when the super hero is sipping his coffee, he's looking at a dashboard that is constructed by reading through these events; in this case, you are taking that entire history, identifying the current state of each of the wars in it, and choosing based on those states what to display.

So under the covers, it might look like

Map<WarId,WarState> wars = new Map();
Set<WarId> interestingWars = new Set();

for(Event e : history.getEvents()) {
    WarState oldState = wars.get(e.warId);
    WarState newState = oldState.apply(e);
    wars.put(e.warId, newState);

    if (newState.isInteresting()) {
        interestingWars.add(e.warId);
    } else {
        interestingWars.remove(e.warId);
    }
}

for(WarId id : interestingWars) {
    display(wars.get(id));
}

'express event name as the verb in past tence not as noun'. So there could be no 'war' event. There could be only 'war started' and 'war ended' events. This clarify this a bit.

Yup, that's really important -- the events are describing things that have already happened; you don't have to think about whether they are "allowed" or not, you just (in this example) need to figure out how to present the information.