Prevent of Aggregate wide calls to EnsureDoesntExist() and EnsureExists() about eventuous HOT 6 CLOSED

I think another reason for moving those methods is Unit Testing. As the Version gets only incremented in Aggregate.Fold() on loading an aggregate from the store an error is thrown when using any method that needs an existing Aggregate. Consider this unit test:

[Fact]
public void Full_Payment_should_leed_to_FullyPaid() {
    IntegrationFixture Fixture = new();
    Booking booking = new();
    decimal amount = 50;

    booking.BookRoom(
        new BookingId(Fixture.Auto.Create<string>()),
        Fixture.Auto.Create<string>(),
        new StayPeriod(
            LocalDate.FromDateTime(DateTime.Today),
            LocalDate.FromDateTime(DateTime.Today.AddDays(2))
        ),
        amount
    );

    booking.RecordPayment(                         // Will fail here as EnsureExists() in RecordPayment() will throw
        Fixture.Auto.Create<string>(),
        amount
    );

    Assert.True(booking.State.IsFullyPaid());
}

The only drawback I can see is that EnsureDoesntExist() and EnsureExists() have to changed from protected to public
If you wan't me to create a pull request, I can do so. Or you find reasons why this approach shouldn't be done ;)

from eventuous.

OnExisting will throw if the aggregate is not found, that's the reason for it to exist.

OnNew will throw when it tries to store, as it expects the stream not to exist.

So, basically, calling EnsureExists and EnsureDoesntExist is not necessary in these cases.

The meaning for those two methods is to enforce those rules inside the model. For example, a certain operation must only instantiate the aggregate, and it cannot be performed on something that already exists. We don't need to even try loading anything from the store, as we expect to have nothing there. We use the expected version, which gets converted to stream state NoStream and it fails on save. It happens in the app service.

However, how would you prevent this operation to be called from the app service using OnExisting? Also, what happens if the aggregate call is made not from an app service?

from eventuous.

I will add your test. It should not throw as the booking state version should increase after BookRoom is called and RecordPayment should not throw.

from eventuous.

I see. I forgot about this obvious thing. There should be two versions. The original version is what we expect to have in the store, to be used for optimistic concurrency. The other version is the current state version, which should increase when state transitions happen. Ensure methods should check the second one.

from eventuous.

Fixed in 78473bc

from eventuous.

@iappwebdev you can check the tests, I added the scenario there and tested all the outcomes, it looks good now.

from eventuous.