How to upcast events

[nyh1030]

First of all, thank you very much for presenting a good methodology.

I'm developing a service utilizing fmodel

I built the event store with fstore-sql and found that all events are handled well.

However, as my business is evolving, the event schema is changing,
I didn't find anything related in the fmodel-ktor-demo or fmodel-spring-demo repositories, so I'm asking here.

Do you recommend upgrading the event store or using event upcasting?

I saw that axon stores @revision as metadata,
I'm confused if I should store additional related metadata in fstore-sql

[idugalic]

Hi @nyh1030 .

Thank you for opening this discussion.
You are right to notice that there is no event versioning in this example. The fstore-sql does not have it as well.

It does not mean we don't need it! I believe that events are API, and like any other API, it is good to evolve it robustly, controlling backward/forward compatibility.

Before we jump into introducing something like a version of the event and a concept of an upcaster I would like to share this link - Schema Evolution and Compatibility. Focus on the summary.

Let's identify the nature/type of that change / Is it backward(breaking) or forward compatible?

1. If the change is one of the two(backward/forward) then you should be fine / no need for an upcaster. You can introduce the event_version column on the events and upgrade that number accordingly: for example 2) Backward comp = Minor 3) Forward comp = Patch.

2. If your change is breaking, but NOT backward or forward compatible, then you need an upcaster. You should introduce the event_version column on the events and upgrade that number accordingly: for example 1) breaking change=Major

I have a couple of projects running in production, and so far We were able to do it as described in section 1 (backward/forward changes). A decision was made not to upgrade the version of the event if the change is backward/forward compatible, for simplicity reasons. That is why we don't have it.

Nevertheless, I would like to introduce the concept of versioning the events into the fstore-sql and into the fmodel. It is a side effect rather than a concern of domain components (decider, view, saga, ...)

• adding an additional column to events table : event_version
• implementing EventRepository to be able to run upcasters on the fetchEvents method.

Would you like to open an issue, referencing this discussion, so we can further collaborate on it? I will try to outline the ideas...

Best,
Ivan

[nyh1030]

@idugalic
Oh thank you so much for your kind explanation.

I would be so grateful for the opportunity to collaborate with you.

Because I'm utilizing Fmodel so well and there are things I'd like to discuss further besides Event Versioning,
Event Versioning is not the only thing I would like to discuss further.

The fmodel repository seems a bit different for the purpose of my question,
which repository should I create my issue in?

For reference, I am developing with Springboot, kotlin environment,
I wanted to discuss this at the implementation level.

[idugalic]

I have opened a PR in this repository to set the ground for introducing a concept of message metadata at first.

• EventRepository is extended with additional methods to support fetching and storing metadata of the event
• Metadata is modeled as a Map<String, Any>.
• Metadata is restricted to the Application layer only. It is a Map. It can be anything/week contract. It does not leak into Domain. All the computations and decisions are done by only using a strong type of the payload/Event/E

Some examples of metadata:

• userId
• traceId
• eventRevision

NOTICE, how userId could be part of the formal Paylod Type/E/C in case authorization is a concern of the Domain core logic. SO, if you don't need these data to make domain core decisions put it in metadata, otherwise, it is part of the strongly typed payload type.

EventSourcingAggregate is enriched with new extensions to expose the handle API to the user:

fun <C, S, E> EventSourcingAggregate<C, S, E>.handle(command: C): Flow<E> =
    command
        .fetchEvents()
        .computeNewEvents(command)
        .save()


fun <C, S, E> EventSourcingAggregate<C, S, E>.handle(
    command: C,
    metaData: Map<String, Any>
): Flow<Pair<E, Map<String, Any>>> =
    command
        .fetchEventsAndMetaData().map { it.first }
        .computeNewEvents(command)
        .saveWithMetaData(metaData)

Once the PR is merged I will update one of the examples to include/propose an event revision concept (I will try to outline the options we have, and choose one)