Search code examples
distributedevent-sourcingevent-driven

Is it okay to model events to encapsulate multiple things that happened at different times


I'm working on a legacy mobile application that needs to be synchronized between multiple devices. It uses event sourcing to perform the synchronization. It is an offline application and business logic is executed within the application rather than in a central location. This seems fine since the domain needs to perform business logic is isolated to a group and synchronization happens only between different devices in the same group. Due to the distributed nature of the system, events that belong to a group (group stream) are ordered by time. Although, existing events are very large and have the following format.

SomethingHappened 
{
    prop1: {
        ...props,
        created_date,
        updated_date, 
    },
    prop2: {
        ...props,
        created_date,
        updated_date,
    }
    created_date // timestamp of the event
}

I'm new to event sourcing and the above format is confusing me. If an event happens at a certain time shouldn't we record it then and there? Is it okay to model events to encapsulate multiple things that happened at different times? If not will this lead to problems in the future?


Solution

  • There's nothing intrinsically wrong with combining multiple events into a single event; it's commonly seen in situations where you want multiple events to be persisted atomically (i.e. all of them get persisted or none of them get persisted). As long as you can be sure that the ordering invariants are being maintained, it's OK.