Control events persistence from the domain model

[alexeyzimarev]

Right now, the event store is agnostic to what events are being persisted. It is quite a limitation for doing things like #64, domain-driven snapshots, closing periods, etc, as some "fold and archive" or "fold and snapshot" actions need to be controlled by the domain model.

For example, a reservation might get archived after the guest checks out, as the lifecycle of the reservation is done, and it becomes fully immutable (or frozen). Similarly, closing a period would collect the period data in a "new period started" event, and then signal the persistence to truncate all the previous events.

So, the idea is to provide a way for the domain model to tell those things to the aggregate store and further to the event store.

I have two ideas atm:

• Apply can get an overload or optional parameter to signal the archiving or truncation
• A set of attributes for event classes to do the same

Both can be implemented at the same time, but the implementation would be in different layers.

• For Apply the change would be to extend the Changes to contain extra information
• For attributes, all the work will be done by the aggregate store. The StreamEvent record would need to get new properties.

[JulianMay]

My 2 cents: I personally like the attribute better, locking in on certain type of events, rather than any event. Although the motivation for archiving is mostly a technical, the implications of it should involve explicit modelling. An explicit event like 'booking archived' would make it simple to handle in downstream consumers, rather than requiring downstream consumers to look for special metadata on any event (theoretically).

[alexeyzimarev]

Yeah, that's true. I don't agree, though, that it's technical. I'd say that archiving for cheaper storage would work with TTLs. The explicit archive is more business-oriented, like in my example for bookings in the issue description.

[JulianMay]

Good point - I was in the realm of "if technology was limitless and for free" (where the business would be happy to simply hide archived data behind an 'IsArchived' flag after a '*WasArchived'-event)... Which, to be clear, is a naive approach to IT for any business and the exact approach I've seen in the wild 🙈

[alexeyzimarev]

I hear more people advocating the idea of explicit serialisation when the domain event can use value objects (which is a problem right now, including conversions back and forth in Apply/When), and it gets manually converted to and from the persisted event. Similar to #153, but two ways (commands are one way).

If that's done, the convertor can return null (or some pre-defined Ignore value) if the domain event doesn't require persistence.

[alexeyzimarev]

The proposal in #168 won't solve the issue of snapshotting and archive controlled by the domain model. However, it might enable it. I will do it first, then look for ways to extend it.