DDD e ValueObjects nel repository

Question

DDD e ValueObjects nel repository

Naviga le tue risposte

#1 da (2 voti)

1

Ho un'entità Product con un oggetto valore Category (esempio forzato).

C'è un endpoint dell'API /products?category=Keyboards,Mice

Le classi in gioco qui sono:

ListProductsController (livello interfacce)
ProductsRetriever (livello applicazione)
ProductRepository (livello dominio / infrastruttura)
Product (entità / radice aggregata)
Category (oggetto valore)

All'interno del modello di dominio, le categorie sono modellate come un elenco di oggetti.

Tuttavia, sono un po 'confuso riguardo al repository. Dovrebbe avere un metodo:

public List<Product> findByCategoriesIn(List<Category> categories)
o
public List<Product> findByCategoriesIn(List<String> categories)

Se dovrebbe essere interrogato usando un ValueObject (cioè Category ) chi dovrebbe convertire l'elenco di stringhe dalla richiesta API nella lista delle categorie?

Dovrebbe accadere all'interno del controller o il servizio applicativo dovrebbe occuparsi della trasformazione?

domain-driven-design

posta NRaf 25.05.2018 - 01:59

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design

WPF: Ricarica le parti dell'app per gestire la persistenza e la gestione della memoria servizi B2B vs B2C: le differenze si riferiscono esclusivamente al processo e al flusso aziendale O ci sono differenze anche nell'architettura tecnica?

score 2 · Accepted Answer

I'm a bit confused with regards to the repository

Non è colpa tua.

Potrebbe essere utile rivedere il capitolo sei del libro blu. Evans scrive

The REPOSITORY retrieves the requested object, encapsulating the machinery of database queries and metadata mapping.

In altre parole, l'API REPOSITORY è espressa nel linguaggio specifico del dominio e le implicazioni indipendenti dal dominio di "Come ottengo questi dati dal / al database" sono inclusi nell'implementazione.

Da questo, puoi dedurre che il consumatore dell'API del repository dovrebbe parlare in valori specifici del dominio, non in primitive agnostiche del dominio.

Questo è coerente con un tema a cui Evans torna ripetutamente; che vuoi che i tuoi sviluppatori trascorrano la maggior parte del loro tempo nel linguaggio specifico del dominio, non manipolando i tipi di dati primitivi.

If it should be queried using a ValueObject (i.e. Category) who should convert the list of strings from the API request into the list of categories?

Quindi la capacità di questa conversione sarà normalmente fornita dal modello di dominio, sotto forma di costruttori di oggetti valore, fabbriche, costruttori di messaggi e così via. Questi strumenti saranno normalmente richiamati dal codice dell'applicazione, prima che tutto si sposti nella vista specifica del dominio.

Detto questo ... c'è stata una sorta di respinta contro questo approccio. È davvero strano iniziare da una stringa, e ora dobbiamo convertirlo in un MumbleId, che viene passato ad un repository che lo convertirà in una stringa da usare come parametro di query, e poi in alcuni documenti / recordset / i byte vengono restituiti, e lo ricostituiamo in un modello di dominio, che poi giriamo e convertiamo in un documento json che inviamo sul filo come byte.

CQRS è, in parte, una risposta alla domanda: non possiamo semplicemente bypassare l'intero modello e copiare i byte di cui abbiamo bisogno? Sì, a volte ha molto senso.