Penso che sia necessario separare due tipi di convalida in questo caso; convalida del dominio e convalida dell'applicazione .
La convalida dell'applicazione è ciò che si ha quando si verifica che la proprietà del comando 'testo' sia compresa tra 20 e 200 caratteri; quindi lo convalidi con la GUI e con un validatore del modello di visualizzazione che viene eseguito anche sul server dopo un POST. Lo stesso vale per l'e-mail (btw, spero che tu ti renda conto 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 porsi la domanda perché l'articolo non dovrebbe esistere se c'è davvero un comando inviato dalla GUI che riguarda l'allegare un commento ad esso. La tua GUI alla fine era coerente e hai una radice aggregata, l'articolo, che può essere fisicamente cancellato 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 precedente, avresti un'infrastruttura che gestisce i messaggi velenosi: per esempio, ripeteranno il messaggio 1-5 volte e poi lo sposteranno in una coda di poision in cui potresti ispezionare manualmente la raccolta di messaggi e ri-inviare quelli rilevante. È una cosa buona da monitorare.
Quindi ora abbiamo discusso:
E i comandi che non sono sincronizzati con il dominio? Forse hai una regola nella logica del tuo dominio che dice che dopo 5 commenti a un articolo, sono ammessi solo commenti inferiori a 400 caratteri, ma un ragazzo era troppo in ritardo con il 5 ° commento e doveva essere il 6 ° - la GUI non l'ha catturato perché non era coerente con il dominio nel momento in cui inviava il suo comando - in questo caso hai un 'errore di convalida' come parte della tua logica di dominio e restituiresti il corrispondente evento di errore.
L'evento potrebbe essere sotto forma di un messaggio su un broker di messaggi o sul tuo dispatcher personalizzato. Il server Web, se l'applicazione è monolitica, può ascoltare contemporaneamente 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 abboni dal punto di vista del server web.
Nel sistema su cui stiamo lavorando, stiamo facendo una richiesta-risposta con comandi / eventi su un bus + broker di messaggi MassTransit + RabbitMQ e abbiamo un evento in questo particolare dominio (modellando un flusso di lavoro in parte) che è chiamato InvalidStateTransitionError . La maggior parte dei comandi che tentano di spostarsi lungo un bordo nel grafico di stato può causare questo evento. Nel nostro caso, modifichiamo la GUI dopo un paradigma alla fine coerente, quindi inviamo l'utente a una pagina di "comando accettato" e in seguito le visualizzazioni del server Web vengono passivamente aggiornate attraverso le sottoscrizioni degli eventi. Va detto che stiamo facendo anche l'event-sourcing nelle radici aggregate (e lo faremo anche per le saghe).
Così vedi, molte delle convalide di cui stai parlando sono in realtà delle convalide di tipo applicativo, non una vera logica di dominio. Non c'è alcun problema nell'avere un modello di dominio semplice se il tuo dominio è semplice ma stai facendo DDD. Continuando a modellare il tuo dominio, tuttavia, scoprirai che il dominio potrebbe non essere così semplice come prima. In molti casi la radice / entità aggregata potrebbe accettare una chiamata al metodo causata da un comando e modificare parte del suo stato senza nemmeno eseguire alcuna convalida, specialmente se ci si fida dei comandi come si farebbe se li si convalida nel server Web che tu controlli.
Posso consigliare e guardare le due presentazioni su DDD da Norwegian Developer Conference 2011 e anche la presentazione di Greg a Öredev 2010 .
Saluti,
Henke