Sto studiando in modo pulito e, di conseguenza, sto ripensando in modo abbastanza drammatico il modo in cui progetto e scrivo software.
La cosa con cui sto ancora lottando, tuttavia, è per le regole di business come "sul salvataggio degli aggiornamenti di un elemento, prima carica tutto l'elenco degli elementi che ho il permesso di visualizzare / modificare ecc., Conferma che questo elemento è nell'elenco, e che la categoria di articoli non è attualmente bloccata dall'uso, (e altre regole, ecc. ecc.) "perché si tratta di una regola aziendale (complessa ma non atipica) e quindi dovrebbe essere gestita nel dominio dell'applicazione piuttosto che inserire la logica aziendale in il livello db / persistenza.
Tuttavia, mi sembra che per controllare efficacemente queste condizioni, sarà spesso meglio gestirlo con una query db ben realizzata, piuttosto che caricare tutti i dati nel dominio dell'applicazione ...
Senza ottimizzazione prematura, qual è l'approccio raccomandato o alcuni articoli di zio Bob che si occupano di questa domanda? O direbbe "convalida nel dominio fino a quando non diventa un problema" ??
Faccio davvero fatica a trovare qualche buon esempio / campione per qualcosa di diverso dal più semplice dei casi d'uso.
Aggiornare:
Ciao a tutti, grazie per le risposte. Avrei dovuto essere più chiaro, sto scrivendo software (principalmente app web) da molto tempo e sicuramente ho già sperimentato e concordato con tutti gli argomenti che descrivi collettivamente (convalida per backend, non fidarti dei dati dei clienti, in generale parlando inseguire l'efficienza grezza solo quando richiesto, tuttavia riconoscere i punti di forza degli strumenti db quando disponibili, ecc. ecc. e aver attraversato il ciclo di vita dell'apprendimento degli sviluppatori di "unire tutto insieme" per "costruire un controller di grasso gigante con applicazioni di livello N" tendenze del codice , e ora piace molto e studia lo stile pulito / di responsabilità individuale ecc., fondamentalmente come il risultato di alcuni progetti recentemente che si sono evoluti in regole di business piuttosto ingombranti e ampiamente distribuite man mano che i progetti si sono evoluti e sono venute alla luce ulteriori esigenze dei clienti.
In particolare, sto esaminando l'architettura in stile pulito nel contesto della creazione di apis REST per funzionalità client-side e per uso interno, in cui molte delle regole aziendali potrebbero essere molto più complesse di praticamente ogni esempio che vedi in rete (anche dagli stessi ragazzi dell'architettura Clean / Hex).
Quindi suppongo che stavo davvero chiedendo (e non sono riuscito a dichiarare chiaramente) come si collocherebbero l'API Clean e un REST, dove la maggior parte delle cose MVC che vedi in questi giorni ha validatori di richieste in arrivo (ad esempio la libreria FluentValidation in .NET), ma dove molti di le mie regole di "convalida" non sono così tante "è questa una stringa di meno di 50 caratteri" ma più "può questo utente che chiama questo utente / interattore eseguire questa operazione su questa raccolta di dati dato che alcuni oggetti correlati sono attualmente bloccati dal Team X fino a fine mese, ecc. ecc. "... quel tipo di convalide profondamente coinvolte in cui sono applicabili MOLTI oggetti di dominio aziendale e regole di dominio.
Devo estrapolare queste regole in un tipo specifico di tipo di oggetto Validator per accompagnare ogni interattore di base utente (ispirato al progetto FluentValidator ma con più logica aziendale e accesso ai dati coinvolti), se dovessi trattare la convalida in qualche modo come un gateway, dovrei mettere quelle convalide IN un gateway (che penso sia sbagliato), ecc. ecc.
Per riferimento, sto uscendo da diversi articoli come questo , ma Mattia non discute molto della validazione.
Ma immagino che la risposta breve alla mia domanda sia molto simile alla risposta che ho accettato: "Non è mai facile e dipende".