Sto studiando su clean e di conseguenza sto ripensando in modo molto significativo a come disegno e software scrivo.
Ho una cosa con cui sto ancora combattendo, è per le regole del business come "salva gli aggiornamenti su qualche oggetto, prima carica tutto l'elenco di elementi che ho il permesso di vedere / modificare ecc., conferma che questo elemento è in la lista, e che la categoria dell'articolo non è attualmente bloccata dall'uso, (e altre regole etc etc) ".. perché questa è una regola aziendale (complessa ma non atipica), e quindi dovrebbe essere gestita nel dominio dell'applicazione piuttosto che premere logica aziendale nel livello db / persistence.
Tuttavia, mi sembra che per controllare in modo efficiente queste condizioni spesso viene gestito meglio con una query db ben realizzata, piuttosto che caricare tutti i dati nel dominio dell'applicazione ...
Senza l'ottimizzazione prematura, qual è l'approccio consigliato o alcuni articoli dello zio Bob che trattano questa domanda? O direbbe "convalidare nel dominio fino a quando non diventa un problema" ??
Sto davvero cercando di trovare buoni esempi / campioni per qualcosa di diverso dal più semplice dei casi d'uso.
Aggiornamento:
Ciao a tutti, grazie per le risposte. Avrei dovuto essere più chiaro, ho scritto (per lo più app web) per molto tempo, e ho sicuramente già sperimentato e concordato con tutti gli argomenti che descrivi collettivamente (convalidato dal backend, non mi fido dei dati dei clienti, in generale inseguire l'efficienza grezza solo quando richiesto, ma riconoscere i punti di forza degli strumenti db quando disponibili, ecc. ecc.) e passare attraverso il ciclo di vita dell'apprendimento degli sviluppatori di "buttare tutto insieme" per "costruire un controller grasso gigante con le tendenze del codice" e ora mi piace e indago sullo stile clean / single responsibility, in pratica come risultato di alcuni progetti che si sono evoluti in regole aziendali piuttosto grezze e ampiamente distribuite mentre i progetti si sono evoluti e sono venute alla luce ulteriori esigenze del cliente.
In particolare, sto osservando l'architettura degli stili Clean nel contesto della creazione di apis REST per le funzionalità client-facing e di utilizzo interno, dove molte delle regole di business potrebbero essere molto altro complesso di praticamente ogni esempio che vedi in rete (anche dagli stessi ragazzi dell'architettura Clean / Hex).
Quindi suppongo che stavo davvero chiedendo (e non avessi detto chiaramente) su come Clean e una API REST si starebbero insieme, dove la maggior parte delle cose MVC che vedi in questi giorni ha validatori di richieste in entrata (es. libreria FluentValidation in .NET), ma dove molte delle mie regole di "validazione" non sono tanto "è una stringa di meno di 50 caratteri" ma più "può questo utente che chiama questo tipo di esecuzione / interazione eseguire questa operazione su questa raccolta di dati dato che alcuni oggetti correlati sono attualmente bloccati dal Team X fino a più tardi nel mese ecc. ecc. "... questo tipo di convalide profondamente coinvolte in cui sono applicabili TANTO di oggetti del dominio aziendale e regole del dominio.
Dovrei far ruotare tali regole in un tipo specifico di tipo di oggetto Validator per accompagnare ciascun interlocutore di casi (ispirato al progetto FluentValidator ma con più logica aziendale e accesso ai dati coinvolti), dovrei trattare la convalida in qualche modo come un gateway , devo mettere quelle convalide in un gateway (che penso sia sbagliato), ecc. ecc.
Per riferimento, sto andando fuori diversi articoli come questo , ma Mattia non discutiamo molto sulla validazione.
Ma immagino che la risposta breve alla mia domanda sia molto simile alla risposta che ho accettato: "Non è mai facile, e dipende".