Scenario: The “Invoice” has a reference to the class “User”. A user object is delete through the user himself or an administrator, but the invoice object still needs a recepient (the user).
The user object could be marked as deleted instead of delete it physically. But I think it is a bad design to use an object, that is marked as deleted. In my opinion objects should only be archived for legal requirements after deletion but not used regularly.
To remove them physically makes some things easier: cascading deletes, selects, database backups …
How can I avoid using objects marked as deleted? What design do I need to be able to remove unused objects physically from the database? Are there best-practises?
Context: OOP (DDD) application based on Java EE and a relational database.
Is this your real world scenario with invoice and user meaning what I think they mean?
Because, I fail to see how an invoice can ever be deleted in the real world. If an invoice is issued to a customer in error, it could be voided, but the physical data cannot be deleted, otherwise you have no way to retain the information which comprises the invoice. If an invoice is valid but a user associated with it is terminated, you still need to be able to see the user associated with the invoice, otherwise you lose the information about who issued or approved the invoice or whatever.
As far as avoiding using objects who are deleted, I don’t think it applies here, because none of these objects CAN actually be deleted. They obviously have an expired, voided, terminated or invalid status for a user creating new invoices or invoices being paid or collected on, but they certainly aren’t deleted in the sense of not existing or being considered to not ever having existed, because they obviously did exist at some point since transactions were committed.