Value entities should use a snapshot journal

With the current implementation, value entities only store the last update. With no snapshot history, consumers of value entity changes may not see every entity change event. This makes it more complex and difficult for developers to understand how changes are passed to change event consumers.

Changing from an update in place to a snapshot journal approach would reduce complexity from a developer perspective.

This change would also likely eliminate production support issues. Imagine a customer scenario where things work most of the time, but in some situations, numerous expected consumer messages are not sent. This has the potential for unexpected catastrophic application failures from the customer’s perspective.

If you want to see all intermediate changes that lead up to a current state you should use event sourcing.

Imagine a customer scenario where things work most of the time, but in some situations, numerous expected consumer messages are not sent. This has the potential for unexpected catastrophic application failures from the customer’s perspective.

The application will always see the latest current state and should be based on that semantics when using the Value Entities. Event Sourced Entity is an alternative model if the application needs to see all individual changes.

If Value Entities and Event Sourced Entities would have the same semantics in this regard it wouldn’t be much benefit of providing the two alternative state models.

The concern is, and the motivation for making this request is the complexity of understanding how state change consumption works. Most developers’ intuition and expectation will be that state change consumers will receive every state change.

Also, will state change consumers see the latest current state in all scenarios? What about deleted entities? What happens when the consumer cannot receive state changes for some reason, and during this offline period, some entities are deleted?

With the current implementation, how this works is not at-most-once, nor is it at-least-once. It seems to be a hybrid where some messages are not delivered, and some messages will be delivered more than once.

1 Like

The model should be easy to understand and consume if you only care about latest value. If you care about the intermediate updates as ”messges” you should use event sourcing instead.

Delete is not implemented yet. There will be some sort of signal that indicates that the entity has been deleted.

1 Like