[Question] purpose of eventually-util::optional::Aggregate

[danieleades]

hi there! I'm just curious what use-case/problem is solved with the eventually-util::optional::Aggregate trait? I have to admit I got a bit confused digging around the codebase by some of the duplicate object names. I think i've got my head around it now!

It seems to me that this trait is meant to be an analogue of the regular Aggregate trait, but that the state may not be seeded until you receive the first event. Is that about right?

Would it be cleaner to simply add a Default trait bound to the Aggregate::State type?

[ar3s3ru]

Hey there!

The optional::Aggregate trait is meant to provide a nicer API for Aggregate states that can be optional (which is probably 99.99% of cases btw).

Specifically, the *_first and *_next methods are an alternative of doing pattern matching on the value of State.

You could still use the base Aggregate trait, this is just a zero-cost abstraction :)

[danieleades]

i sketched an alternative version of the example app using a state machine - https://github.com/danieleades/eventually-example (more for my own interest than anything else!)

Interested to know your thoughts

[ar3s3ru]

I like the implementation, but I have some questions:

1. Order is defined here, but where would you use it? As it is, that looks to me like an Aggregate Root.
2. Is it possible to commit an Order with State::NotStarted?

[danieleades]

• Order is defined here, but where would you use it? As it is, that looks to me like an Aggregate Root.

Order<S> is a state machine that only allows defined state transitions (defined in the impl blocks). As such, it's not possible to misuse. This in turn is wrapped in an enum, which gives you dynamic dispatch. It's true that in this example the majority of the logic is fully encapsulated by the state machine, meaning the Aggregate delegates much of its functionality to the State. In other examples the Aggregate could have additional responsibilities, such as making database queries or whatever.

• Is it possible to commit an Order with State::NotStarted?

No. Because of the signature of Aggregate::apply it must always apply at least one event, so at minimum you'll always have either an editable order, or an error.

To be clear, i'm not necessarily suggesting this is a better pattern! I just thought it might be an interesting counterpoint to consider.

[ar3s3ru]

It is interesting indeed, but Order is basically doing what an AggregateRoot is supposed to do already, which is:

only allows defined state transitions (defined in the impl blocks). As such, it's not possible to misuse. This in turn is wrapped in an enum, which gives you dynamic dispatch.

Since AggregateRoot is a library-defined type (since it has to be returned by the Repository), in order to provide "dynamic dispatch" of methods to manipulate the State I had to introduce Aggregate::Command (typically used as an enum) for doing the exact same thing.

I have experimented with some additional design and it would be more similar to your Order<State> example.

I'll probably tag you in the issue for Aggregate Root design in v0.5.0 and we can discuss this further, if you're interested 😄

[danieleades]

I'll probably tag you in the issue for Aggregate Root design in v0.5.0 and we can discuss this further, if you're interested

please do!