Dove va la logica di convalida complessa e pesante?

Ho faticato a capire un modo pulito per convalidare le cose quando gli oggetti hanno relazioni complesse e la convalida richiede operazioni costose (ad esempio, effettuare query DB o altri RPC).

Guardandomi intorno, non sono riuscito a trovare qualcosa che risponda a questa domanda, quindi ecco qui. Ho letto un po 'del design guidato da domini, dei modelli di dominio, dei livelli di servizio, dei mappatori dei dati, degli script di transazione e dei modelli di dominio anemico-ricco; c'è molto ed è travolgente con le varie opinioni.

Ad esempio, diciamo che abbiamo un oggetto Document , e ha un elenco di nomi utente, ma ti è permesso solo avere nomi utente per gli utenti attivi . Controlla se un utente è attivo chiamando ad un UserService esterno. Questo esempio può facilmente crescere aggiungendo, ad esempio, allegati, impostazioni di condivisione, ecc. Che possono essere utilizzati con un documento solo in determinate condizioni e hanno anche i propri invarianti interni / convalida o richiedono più chiamate al database o altri servizi esterni.

Ma, solo dove fa / dovrebbe avvenire la convalida?

1. Al livello in cui vengono raccolti gli input dell'utente? Lasciando da parte la possibilità per altri punti di input o più codice interno di ignorare questa regola (o più probabilmente, copia / incolla una versione leggermente diversa di essa intorno)?
2. Sull'oggetto Document stesso? Il che risulta in uno strano legame tra l'oggetto Document e la dipendenza heavyweight (ad es., Come argomento di costruzione, o un argomento richiesto a qualche funzione isValid )
3. In fondo in un livello di persistenza, quindi è sempre applicato, ma confusa la persistenza con la logica aziendale?
4. In qualche strato intermedio? Resta ancora la possibilità che più codice interno passi direttamente al livello di persistenza e salti la regola?

Man mano che la complessità aumenta, diciamo che il salvataggio di un Document ora ha una funzione in cui creerà automaticamente un Attachment (che può essere creato indipendentemente e avere anche i propri invarianti / convalida interni) - come fare struttura / progetto / architetto l'applicazione per evitare il tipo di problemi / cortocircuiti come menzionato sopra mentre le cose crescono e cambiano?