DTO per conservare i dati più disparati dal modello di dominio?

Question

DTO per conservare i dati più disparati dal modello di dominio?

#1 da (3 voti)

0

Ho un modello di dominio ordinato che semplifica la comunicazione con un servizio Web esterno. I nuovi requisiti hanno reso l'interfaccia del servizio Web esterna disordinata e ora devo raccogliere dati da più punti nel mio modello. Un DTO è appropriato per contenere tutti i dati necessari?

Ho un'interfaccia che si occupa della ricerca di alcuni modelli di dominio. L'implementazione concreta che ne deriva va a un servizio Web esterno per i risultati.

interface IConsentSearch    // only one method
 +Search(Customer) : IList<Consent>

class Customer
 +various properties

Il mio modello di dominio è, ovviamente, molto più complesso, ma questo è il succo di ciò.

Ora ho alcuni nuovi requisiti che ci consentono di cercare in order id oltre alle proprietà di Customer . Nel mio modello di dominio interno, orderId ha una sua piccola posizione da qualche parte (non parte di Customer ). Il problema è che l'interfaccia del servizio web esterno ha un'idea completamente diversa di dove orderId è.

Nota : non è una o entrambe le situazioni: tutto ciò che Customer deve offrire è obbligatorio per la ricerca: order id è solo un criterio aggiuntivo.

Dovrò cambiare Search() signature e ho pensato di creare un nuovo DTO nel livello di servizio dell'applicazione chiamato ConsentSearchDTO . Il nuovo DTO servirebbe uno scopo: combinare dati e modelli che sono ora sparsi nel mio modello di dominio e necessari per interrogare il servizio web esterno:

interface IConsentSearch    // still only one method
 +Search(ConsentSearchDTO) : IList<Consent>

class Customer      // still the same
 +various properties

class ConsentSearchDTO
 +Customer : Customer
 +OrderId : int

Le mie domande:

La percentuale di% co_de ha senso?
Va bene creare un DTO che faccia riferimento alle classi del modello di dominio ( ConsentSearchDTO ) o dovrei creare una struttura completamente nuova che imita il modello di dominio originale? Sembra molto lavoro e non mi porta alcun valore aggiuntivo.

design domain-driven-design dto

posta robotron 12.02.2018 - 19:16

fonte

1 risposta

Leggi altre domande sui tag design domain-driven-design dto

Utilizzo di metodi specifici per una sottoclasse Grammatica per esempio

score 3 · Accepted Answer

Sembra che tu stia affrontando due problemi diversi:

Hai un nuovo requisito: cerca un Consent di un OrderId .
In qualche modo l'API del componente di ricerca è cambiata (o deve essere modificata per questo requisito).

Una modifica all'API Web non dovrebbe influire sull'interfaccia IConsentSearch . Questo è il punto centrale di questa astrazione. Tutto ciò che devi fare per far funzionare la tua applicazione con la nuova API deve avvenire nel modulo che implementa IConsentSearch (chiamiamolo WebConsentSearch ).

Ora sembra che il nuovo requisito richieda una modifica a IConsentSearch . Ma l'interfaccia deve servire il modello di dominio ed essere espressa in termini di dominio. Quindi la tua interfaccia dovrebbe avere un nuovo metodo come SearchByOrderId(Customer, OrderId) ed è di nuovo il lavoro di WebConsentSearch a occuparsi di questo.

Per rispondere alle tue domande:

In background, WebConsentSearch può utilizzare tutti i tipi di oggetti valore per passare i dati tra i componenti secondari coinvolti.

Ma il termine DTO o ValueObject non ha posto nel tuo livello di dominio e non devi introdurre nuovi oggetti di dominio solo allo scopo di semplificare la vita della tua infrastruttura. Il tuo dominio non "sa" quali sono i bisogni dell'infrastruttura.
In linea di principio, questi oggetti valore possono avere un riferimento a una classe di dominio. Tuttavia, nella maggior parte dei casi non è la migliore idea. Invece, dovresti probabilmente avere un adattatore che traduce l'oggetto dominio in tipi di dati più basilari che forniscono tali informazioni in un formato conveniente per il tuo client API web.

Il "valore aggiunto" è che solo l'adattatore dipende dal modello di dominio, rendendo l'API più facile da modificare e più facile da testare.

_{[Un DTO è, in senso stretto, per trasferire dati tra processi. Ho cambiato la mia risposta per usare il termine più appropriato 'oggetto valore' sopra, anche se penso che non sia raro usare i termini in modo intercambiabile. In ogni caso, un DTO effettivo non dovrebbe in genere contenere oggetti di dominio, poiché i DTO devono essere facilmente serializzabili. Vedi anche qui ]}