The trouble with soft delete. Soft delete is a commonly-used pattern amongst database-driven business applications.
In my experience, however, it usually ends up causing more harm than good. Here’s a few reasons why it can fail in bigger applications, and some less-painful alternatives to consider. Tomato, Tomato I’ve seen a few different implementations of this pattern in action. First is the standard deleted flag to indicate an item should be ignored: Strengthening your domain: a primer. Posts in this series: Recently, I talked some about the idea of an intentionally anemic domain model, under the name of “Persistence Model”.
While a Persistence Model is great for a large percentage of projects, you may eventually want to move more behavior into the domain. That doesn’t mean a bevy of domain services doing the actual work, however. A strong domain means that our objects become more behavioral, and less as solely data-holders. But before we get into some of the patterns, what are some of the goals we want to achieve with a stronger domain?