CODEWITHSUNDEEP
c#architectureevent-handlingcqrsevent-sourcing
Alex
Alex

Reputation: 519

In CQRS and Event Driven Architecture, Should State Changes generated at the read side create more events?

Lets say I am creating a bidding website that is Event Sourced and uses CQRS.

Here are our two basic Entities:

public class Auction {
    int Id {get; set;}
    //Active, Closed
    AuctionStatus Status {get; set;}
    Bid? HighestBid {get; set;}
    double StartingBid {get; set;}
}

public class Bid{
    int Id {get; set;}
    double Value {get; set;}
    //Accepted, Rejected, Created
    BidState State {get; set;}
}

My Command Side has 2 Commands:

The Command Side simply verifies that an Auction Exists and that the Bid amounts are in a range of accepted vales and then issues an event to be handled by the query side.

When we Create an Auction it is saved to the Aggregate Database with an 'Active' Status

When we make a bid it comes to the read side in the 'Created' Status and then can have its state updated depending on the current state of the Aggregate data.

For example:

In order to make the rejection of this Bid more auditable, we save a 'BidStateChange' to the aggregate database that simply includes the BidId, A Reason Code, and the new state:

public class BidStateChange {
  int BidId {get; set;}
  BidState newBidState {get; set;}
  string Reason {get; set;}

}

First we Update our Bid's state to Rejected, then we save a BidStateChange

My question is, should this state change issue an event to the Event Steam or Not?

My inclination is NOT to issue the state change to the event stream because we will otherwise be duplicating events on replay. Consider this:

Lets say we do issue an event for the BidStateChange, We replay the following Events:

1. Create Auction -> 2. Low Bid Placed -> 3. Bid State Changed to Reject

When we replay these events, wouldn't that result in the 'Reject State Change' being created twice? The first time as a result event 2 and then again at event 3. because we are replaying all of our event history?

Maybe I am overthinking 'replayability' maybe it makes more sense to alert that a bids state was changed in case other microservices need to know the current state of any bids.

Can anybody with more Experience to this architecture advise? Thanks!

Upvotes: 1

Views: 293

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57214

Should State Changes generated at the read side create more events?

"State changes generated at the read side" is a very... odd... spelling to use in the CQRS pattern.

In the usual arrangement, information from "the outside" is delivered to the write model, and that's where we perform our computation to decide what the new "authoritative" state of the entity is.

The read model is a non-authoritative copy of state; accurate as of some point in the past, but not necessary up to date. Think "cache".

State changes generated by the cache is weird, because the cache is reflection of the write model.

Now, what will sometimes happen, is that we have two models, and the second model will be interested in changes that happen to the first model.

In that case, we use some form of plumbing to connect the outputs of one model to the inputs of the other.

So we have Alice doing her work, and one of the reports (read model) produced by Alice's work becomes one of Bob's inputs as he does his work.

Now, you might -- as a matter of optimization -- broadcast "events" when the caches update, so that subscribers can know that there is information available for processing. But you probably shouldn't be framing these as "state changes" in the sense of being changes to the entities in your domain model. Those changes have already happened, under the governance of the write model.

Upvotes: 1

Related Questions