It could, indeed. Then we should change isDeleted() so it also returns true when !empty($this->deleted_at), or not? I don't want to make things more complicated at the moment.

save() would work, but would generate updated/updating event which we don't need/want.

The question is then how the complete process of deleting a domain (or a user for that matter) is reflected in real life, vs. the database record.

I believe I intended for the database to reflect in 'deleted_at' the semantics for UI/UX -- including billing and pro rata temporis if you will, and for STATUS_DELETED to be the final confirmation.

In a sense, deleting could spawn the dispatched process -- it creates a series of actions to need to have occurred much like creating a user does (ldap ready, imap ready).

I think it is there where I figured STATUS_DELETED would add value compared to just deleted_at.

I think we need to settle what deleting and deleted is compared to deleted_at vs. STATUS_DELETED, before we need to consider $domain->save() and its triggering of updating()/updated().

Think... "remove entitlements billed to wallets owned".

When john@kolab.org owns a wallet to which all entitlements associated with any @kolab.org-related entitlements are billed -- and how would he not?? --, then iterating over his wallets and entitlements billed to said wallets is a very predictable path.

$domain -> $domain_id.

This should really be:

return $this->select(['users.*', 'entitlements.wallet_id'])

because Query\Builder::select() only supports 0-1 parameters (see phpstan output).