Is it possible to work directly with an Aggregate and call its methods without Commands and Command Handlers?

[alexeyfv]

Hello,

I know that EventFlow documentation has an example with Commands and CommandHandlers.

But is it possible to work directly with an Aggregate and call its methods without using CQRS? For example, something like this:

public class Example(IRepository repository)
{
    public void DoSomething()
    {
        TAggregate aggregate = repository.LoadAsync<TAggregate>(id);
        aggregate.DoSomething();
        repository.SaveAsync(aggregate);
    }

    public void DoSomethingElse()
    {
        TAggregate aggregate = repository.LoadAsync<TAggregate>(id);
        aggregate.DoSomethingElse();
        repository.SaveAsync(aggregate);
    }
}

[rasmus]

@alexeyfv yes it is. Simply use the IAggregateStore.UpdateAsync<,> method 😄 When building EventFlow, I have tried really hard to make sure each class has a small and simple responsibility. Often you will find that the amount of code in each class of EventFlow is rather limited, yes there are some that have some complexity, but they are few. Ideally, while there are a lot of literature on event sourcing that would like to tell you how you should do it "properly", the fact is that sometimes you just need to get "stuff" done. EventFlow tries really hard to expose everything you need in order to allow you to work with event sourcing how you think is best.

[alexeyfv]

If I understood correctly from the source code of CommandBus, when using UpdateAsync method, we should provide SourceId. For example, CommandBus uses and ID of the command. The Command class itself uses an ID from CommandId class.

Then this SourceId is used in UpdateAsync method, which basically just checks if the aggregate already has such SourceId.

Does this mean that the SourceId is a unique ID, which helps to prevent multiple processing of the same update? And I can specify any random ID as the SourceId using the same approach as in Command class:

public class WorkerId(string value) : Identity<WorkerId>(value), ISourceId { }

await _store.UpdateAsync<WorkerAggregate, WorkerId>(
    workerId, 
    WorkerId.New, 
    (worker, _) => worker.Start(), 
    ct);

[rasmus]

Yes, SourceId is merely there to prevent the same operation being applied twice. Its checked here

https://github.com/eventflow/EventFlow/blob/develop-v1/Source/EventFlow/Aggregates/AggregateStore.cs#L128-L135

If you don't care about the source id, you can invoke the SetSourceIdHistory from within the aggregate root to limit the amount of history stored in-memory.

[alexeyfv]

Thanks. I implemented the approach with IAggregateStore, and it works fine. What do you think about adding some examples with IAggregateStore to the documentation?

[rasmus]

Definitely! The documentation is severely lacking. Personally I have a hard time of adding stuff when I sit down to actually write something, so if you have an idea of something specific, then awesome ❤️

[alexeyfv]

Ok. I'll close this discussion, prepare an example with IAggregateStore and open pull request.