Looking toward EventFlow v2

[rasmus]

While I have no specific plans for v2 of EventFlow, planning for it makes sense. Ideally it would properly make sense to align the release with the next .NET 10 LTS release as to use that to add .NET 10 support as well as remove support for the then deprecated .NET versions.

First off, as with any EventFlow release, care is taken to minimize the number of breaking changes and ensure no data migrations are needed. Systems built on EventFlow tend to be old, complicated and have enormous data volumes, thus its important for any user of EventFlow that upgrading to newer versions is easy and safe.

Here are some thoughts on what might be included in a v2 release (nothing is final!). Some are topics I have put off for doing for v1 as to keep the scope down a bit, others are ideas that have come up over the last couple of years.

• Create a EventFlow.Abstractions (or some other name) that contains e.g. the value objects (ValueObject and SingleValueObject) that developers have used outside EventFlow enabled projects. Typically, these have been used in e.g. "contract" packages and having the entire EventFlow package referenced severely bloats dependencies of what should be a simple contract.
• Finally, split Newtonsoft.Json out into a separate package and rely on System.Text.Json by default in the core package. There have been many issues and PRs on this and finally getting it done would be awesome. However, since many rely on this working perfectly today, it has to be carefully done in order to ensure existing setups continue to work.
• ReadModelLocator async support #1061
• Provide more metadata to snapshot upgraders #919

I'll update this issue with ideas and suggestions if any are posted. If anyone have ideas, let me know.

[MMonrad]

Hello @rasmus,

If you have any interrest in getting help to version 2, I could have an interrest in giving a hand. Specially with the splitting of Newtonsoft.Json and System.Text.Json.

[macsux]

I would really love to see support for aggregates acting as command handlers, as frequently it just wants to modify itself in response to some command. Axon framework does this.

Can be done quite easily with code generators that do something like this:

public partial class StoryAggregate : AggregateRoot<StoryAggregate, StoryId>
{
    [CommandHandler]
    public void Handle(LinkArticleToStoryCommand command)
    {
        
    }
}

would get extended via generators like this:

public partial class StoryAggregate
{
   public class LinkArticleToStoryCommandHandler : CommandHandler<StoryAggregate, StoryId, LinkArticleToStoryCommand>
    {
        public override async Task ExecuteAsync(StoryAggregate aggregate, LinkArticleToStoryCommand command, CancellationToken cancellationToken)
        {
            aggregate.Handle(command);
        }
    }
}

[github-actions[bot]]

Hello there!

We hope you are doing well. We noticed that this issue has not seen any activity in the past 90 days. We consider this issue to be stale and will be closing it within the next seven days.

If you still require assistance with this issue, please feel free to reopen it or create a new issue.

Thank you for your understanding and cooperation.

Best regards, EventFlow

[rasmus]

@MMonrad I think what would be needed to make it easier for developers to migrate, would be to add the System.Text.Json as a minimal add-on option for v1 using an extension method for the configuration.