DTO vs Modelli di dominio e invocazione diretta dei gestori di comandi

Purtroppo, non sono sicuro di quale sia la tua prima domanda, quindi non sono in grado di rispondere, ma posso aiutarti con il resto.

2) We're currently performing validation on the request data before passing it into our immutable command objects. However, there may be some cases where we need parse data from the DB/CLI prior to initializing our commands.

As a result, I've considered placing our validation logic into the command objects themselves. If validation fails then a exception might be thrown. Does this seem like a reasonable approach or am I again violating some design principles?

Cosa dovresti chiedere tu stesso perché hai a che fare con oggetti non validi in primo luogo in modo che richiedano la convalida dopo che sono stati creati?

Ci sono due situazioni perché questo potrebbe accadere:

• non ti fidi delle variabili che vengono utilizzate quando viene creato un oggetto
• non ti fidi degli oggetti stessi, non ci credi, che ciò che stanno facendo con i loro dati è perfetto

Entrambi questi casi sono cattivi, ma il secondo è molto peggio.

Il primo caso può e succede quando si usano le variabili, su cui l'utente ha il controllo. Vale a dire. può inserire tutto ciò che vuole. Questo è qualcosa su cui non hai alcun controllo, quindi assicurati di controllare le opzioni tutte prima di creare un oggetto.

Il secondo caso accade quando, anche se modelli una classe, non ti fidi che la classe faccia ciò che dovrebbe fare. Esponete forse troppo della sua struttura interna, dando al programmatore troppe possibilità su come operare sull'oggetto, magari con semplici getter e setter, invece di metodi reali?

Ho detto che il secondo caso è peggio. Il motivo per cui è peggio è perché non ti fidi del tuo dominio. E se non ti puoi fidare, allora chi?

3) This may sound foolish but what exactly is the difference between a Domain Object and a DTO. I've heard the command objects themselves being referred to as a DTO yet they appear to belong to the domain layer (unless I'm mistaken).

DTO è un oggetto molto semplice e stupido che consiste solo di getter e setter e incolla piccoli blocchi di informazioni apparentemente correlate insieme per creare una struttura più grande, in modo che le richieste di dati possano essere ridotte.

Martin Fowler fornisce un semplice esempio di oggetto DTO.

Modello di dominio è un oggetto contenente la tua logica aziendale. È un oggetto che non dovrebbe avere metodi che iniziano con il prefisso set , dovrebbe seguire il principio Tell, Do not ask , ecc. Il dominio è il nucleo della tua applicazione, gli oggetti del dominio assicurati che tutto funzioni bene, generano eccezioni di dominio su operazioni non valide per assicurarti che siano sempre in uno stato valido.

Il principio Tell, Do not ask fornisce l'incapsulamento. Trasforma questo:

if (personObject.GetSex() == "Male") { ... }

in questo:

if (personObject.IsMale()) { ... }

Il programmatore che utilizza una classe Person non se ne preoccupa più, come viene rappresentata la proprietà Sex , se è un string , un enum o un boolean . L'unica cosa che importa è il metodo Person::IsMale : boolean .

Riepilogo del modello di dominio: è un oggetto che contiene dati che sono direttamente collegati ad esso (non è consentita la logica di persistenza, l'oggetto deve trattare solo con i propri dati) e incapsula le operazioni per essere sicuro una volta creato, non si troverà mai in uno stato non valido.

Non ho molta esperienza in questi termini, ma ho fatto molta serializzazione con tipi di dati davvero complessi con tutti i tipi di strane dipendenze, quindi ecco i miei 2 centesimi sulla gestione dei POCO (TLDR, mantieni POCO) .

I have identified some cases where we would actually need to parse the API response data on runtime. Could this be construed as a potential issue in the design of our application?

Sì, dovresti aver finito con l'elaborazione di tutti i dati che ricevi il prima possibile. Altrimenti potresti finire con un sacco di codice spaghetti in tutti i livelli dell'applicazione facendo de / serializzazione 'su richiesta'

I've considered placing our validation logic into the command objects themselves. If validation fails then a exception might be thrown. Does this seem like a reasonable approach or am I again violating some design principles?

Sì, alcune convalide potrebbero richiedere dati da altri oggetti, alcuni potrebbero richiedere del tempo, alcuni risultati di costosi algoritmi utilizzati per la convalida potrebbero essere necessari per accedere più volte. Potrebbe essere necessario fare qualcosa se la convalida fallisce che potrebbe includere dire al server web che la validazione fallisce. per questo o devi usare alcuni delegati o eventi o farlo proprio lì. entrambi significano chiamare la libreria di rete, non bella e ovviamente creare altri DTO in un DTO, tutti i tipi di spaghetti lì.