DDD Request Validation Handling

1

Ho bloccato da qualche parte che non riesco a trovare una soluzione! Ci sono molte domande di convalida qui, ma per quanto vedo, la maggior parte di loro stava chiedendo la convalida dell'entità. Ma per quanto riguarda la convalida delle richieste?

Sto sviluppando un servizio per l'applicazione web. Fondamentalmente ho 3 moduli che sono Web, Domain e Repo. Una richiesta di progetto Web ha dipendenze da altre tecnologie (classi generate automaticamente da JAX-WS) e non sono adatte per essere utilizzate nel dominio. Quindi li converto in una nuova classe di richieste per renderlo più adatto al servizio di dominio. Aggiungo anche i metodi default () e validate () alla nuova classe di richiesta. Quindi una parte della convalida della richiesta viene gestita nel metodo validate () . Li chiamo alla prima riga del metodo corrispondente nel servizio di dominio. Quindi, prima di iniziare l'operazione, so se la richiesta è valida o meno. Più tardi, ho dei codici di convalida. A questo punto, non sono molto sicuro che quale parte della convalida sia veramente valida per la convalida delle richieste e quale parte di essa appartenga al servizio di dominio come logica aziendale. Credo che ogni pezzo di codice appartenga a quello che deve essere! Ma a volte è difficile decidere: D Ad esempio quando è necessario utilizzare il repository mentre si sta convalidando. Lascia che ti spieghi con l'esempio.

Diciamo che è necessario implementare un metodo in cui i clienti possono essere aggiunti o eliminati dall'account. A parte il controllo nulla (validation-phase1), è possibile verificare se il cliente è valido o meno. Hai bisogno di un repository. Quindi verifichi che entrambi gli account siano aperti o meno. Hai bisogno di un repository. Boom! Poi controlli se il cliente in richiesta è già stato aggiunto o se tenti di eliminare il cliente che non appartiene all'account e così via ... Potresti pensare che quelle situazioni non siano una convalida, ma una logica di business. Penso che siano la convalida, perché prima, controlli clienti e account, poi fai altre cose. Cosa ne pensi dell'utilizzo del repository dal metodo di validazione, qual è il tuo vantaggio per la validazione? Consideri la situazione sopra menzionata come una convalida? Grazie in anticipo.

    
posta Adem İlhan 25.06.2015 - 09:19
fonte

2 risposte

1

Prima di tutto, se hai un account aggregato e un cliente aggregato, e la regola aziendale per la modifica di un account aggiungendo un cliente richiede lo stato del cliente e allo stato dell'account, quindi le tue regole aziendali o il tuo il modello è sbagliato Il limite aggregato è quello di includere tutti gli stati necessari per applicare l'invarianza di business.

Tutte le convalide delle regole aziendali appartengono all'aggregato proprietario dello stato sottoposto a verifica.

Tutta la convalida sugli argomenti al comando - questo è davvero un cliente, è davvero un numero compreso tra 1 e 100 e così via - quella logica appartiene al di fuori dell'aggregato. Fa parte della convalida del comando eseguita dal gestore di comandi (sebbene sia utile avere la stessa logica di convalida generalmente disponibile - il client dovrebbe essere in grado di convalidare un comando prima di inviarlo al gestore di comandi da passare all'aggregato).

    
risposta data 16.01.2016 - 07:21
fonte
0

Le regole di convalida sono logiche di business.

Anche un semplice controllo "NULL" è una regola aziendale: qualcuno ha deciso che era OK per "Nome intermedio" da non perdere, ma "Contea" deve sempre essere compilato.

La maggior parte delle regole di validazione non è così semplice e potrebbe persino richiedere l'accesso a servizi esterni, ad es. "è il ragazzo sulla lista di agenzie di credito s ** t".

Quindi dimentica la convalida come passaggio separato, non sono nemmeno una regola aziendale "speciale", in qualsiasi applicazione che si occupa di input esterni la maggior parte delle regole aziendali sarà una sorta di convalida.

Avendo detto che la convalida rientra in due categorie generali: -

"è la richiesta ben formata" - sono i numeri dei numeri, i campi obbligatori sono compilati ecc. Questi controlli possono essere fatti in anticipo (spesso nel browser web dei richiedenti) e non richiedono l'accesso a nessun dato esterno.

"sono i contenuti validi" - questo quasi sempre richiede l'accesso ad altri dati.

Il vero problema è confondere un sottoinsieme di convalida "verifica che la richiesta sia ben formata" con l'intera validazione.

    
risposta data 16.01.2016 - 08:34
fonte