Penso che in questo caso sia necessario separare due tipi di validazione; convalida del dominio e convalida dell'applicazione .
La convalida dell'applicazione è quella che hai quando verifichi che la proprietà del comando 'text' è compresa tra 20 e 200 caratteri; quindi lo convalidi con la GUI e con un validatore del modello di vista che viene eseguito anche sul server dopo un POST. Lo stesso vale per l'e-mail (a proposito, spero che tu realizzi che un'e-mail come `32.d +" Hello World .42 "@ mindomän.local" è valida secondo la RFC).
Quindi hai un'altra convalida; controlla che l'articolo esista: devi porti la domanda sul perché l'articolo non dovrebbe esistere se esiste effettivamente un comando inviato dalla GUI che riguarda il collegamento di un commento. La tua GUI è stata infine coerente e hai una radice aggregata, l'articolo, che può essere fisicamente cancellata dall'archivio dati? In tal caso, basta spostare il comando nella coda degli errori perché il gestore comandi non riesce a caricare la radice aggregata.
Nel caso sopra, avresti un'infrastruttura che gestisce i messaggi velenosi, ad esempio riproverebbero il messaggio 1-5 volte e poi lo sposterebbero in una coda di avvelenamento dove potresti ispezionare manualmente la raccolta di messaggi e rispedire quelli pertinenti. È una buona cosa da monitorare.
Quindi ora abbiamo discusso:
Che dire dei comandi non sincronizzati con il dominio? Forse hai una regola nella logica del tuo dominio che dice che dopo 5 commenti a un articolo, sono consentiti solo commenti inferiori a 400 caratteri, ma un ragazzo era troppo tardi con il 5 ° commento ed è diventato il 6 ° - La GUI non l'ha presa perché non era coerente con il dominio nel momento in cui inviava il suo comando - in questo caso si verifica un "errore di convalida" come parte della logica del dominio e si restituisce l'evento di errore corrispondente.
L'evento potrebbe essere sotto forma di un messaggio su un broker di messaggi o sul proprio spedizioniere personalizzato. Il server Web, se l'applicazione è monolitica, potrebbe ascoltare in modo sincrono sia un evento di successo che l'evento di errore menzionato e visualizzare la vista / parziale appropriata.
Spesso hai un evento personalizzato che significa fallimento per molti tipi di comandi, ed è questo evento a cui ti iscrivi dal punto di vista del web server.
Nel sistema su cui stiamo lavorando, stiamo facendo una richiesta-risposta con comandi / eventi su un bus di messaggi + broker MassTransit + RabbitMQ e abbiamo un evento in questo particolare dominio (che modella in parte un flusso di lavoro) che è chiamato InvalidStateTransitionError. La maggior parte dei comandi che tentano di spostarsi lungo un bordo nel grafico dello stato può causare questo evento. Nel nostro caso, stiamo modellando la GUI secondo un paradigma alla fine coerente, e quindi inviamo l'utente a una pagina di "comando accettato" e in seguito lasciamo che le visualizzazioni del server Web si aggiornino passivamente attraverso le sottoscrizioni di eventi. Va detto che stiamo anche facendo il sourcing degli eventi nelle radici aggregate (e lo faremo anche per le saghe).
Quindi, vedete, molte delle convalide di cui state parlando sono in realtà convalide del tipo di applicazione, non una vera logica di dominio. Non c'è nessun problema ad avere un modello di dominio semplice se il tuo dominio è semplice ma stai facendo DDD. Mentre continui a modellare il tuo dominio, tuttavia, scoprirai che il dominio potrebbe non essere così semplice come si è scoperto. In molti casi la radice / entità aggregata potrebbe semplicemente accettare un'invocazione di metodo causata da un comando e modificare parte del suo stato senza nemmeno eseguire alcuna convalida, specialmente se ti fidi dei tuoi comandi come faresti se li convalidassi nel server Web che tu controlli.
Posso consigliare di guardare le due presentazioni su DDD della Norwegian Developer Conference 2011 e anche la presentazione di Greg a Öredev 2010 .
Saluti, Henke