[EdwardDiego]

As opposed to event sourcing, which every time I've seen it in use, contains a bug ridden slow implementation of event sourcing.

Seriously, event sourcing is hard to do right, maybe soft delete is the simpler approach, it depends on what you're doing.

[nivertech]

The problem is that people’s first choice is to use generic models like CRUD/CRUD-L/REST/etc., instead of unvesting a bit of time in upfront thinking/design and building a custom model.

IMO, if entity might be resurrected/revived/“undeleted”, then it either cannot be killed/deleted, or more likely what you thought as “deletion” was something else (e.g. suspending, archiving, hiding, or putting into trash bin).

It’s better to model a lifecycle of such an entity as an FSM.

And yes, Event Sourcing might be harder in some respects, but it’s make things easier in others, as it makes soft-delete and tens of other design patterns redundant.

[EdwardDiego]

I've never seen it done well, and yeah, it sounds good in theory, in reality, blurgh.

[to11mtm]

I've seen it done fairly well, or at least 'doable if wanted but not turned on'.

IME, ideal state is that 'soft deletes' are kept primarily for easing debugging, and the 'soft delete' is kept until archival of soft deleted events occurs (also primarily for debugging/compliance, but sometimes having 'recent data' closer to runtime makes debugging cycles easier...

The biggest problem in doing so successfully is getting the design of things right, which is hard to get buy-in on.

[nivertech]

> I've never seen it done well,

IMO, this is b/c it takes years to learn and apply, on top of already having significant CRUD experience

Corporate drones are not incentivized to do this, and startup people are pressed with time

So it may only work if there are highly motivated people, who may peridically ask for help from expirienced consultants, but not fully rely on them.

So do it this way:

> It’s better to model a lifecycle of such an entity as an FSM