Come interrogare un oggetto figlio all'interno di una radice aggregata su richiesta?

3

Sto imparando DDD. Per una pratica, sto provando a convertire la mia app in aggregati DDD.

Quello che ho capito finora su aggregato.

  1. L'aggregato definisce il limite della transazione
  2. Design aggregato il più piccolo possibile
  3. Se non esiste alcuna invariante da proteggere, potrei non aver bisogno di un aggregato.
  4. Devi caricare tutto da un aggregato.

Ho un semplice esempio. Quando un utente carica un'immagine e informazioni sull'immagine, la mia app crea prodotti basati sull'immagine.

Ho Asset aggregato e Asset ha molte Product entità (?)

class Asset
{
     public function newProduct(ProductType $productType) {
       // return a new Product object then save id internally
     }
}

Quando aggiungo un nuovo prodotto a Asset, salvi l'id prodotto su Asset. Quando carico Asset dal proprio repository, ho un problema. Poiché ho più di 30 tipi di prodotto, non è ottimale caricare tutti i prodotti insieme. Poiché un prodotto non può esistere senza un asset e un id prodotto deve essere persistente in un asset, ho una logica aziendale da proteggere.

Devo davvero caricare tutti i prodotti quando carico un asset?

Posso avere un metodo in Asset che accetta un DAO per recuperare un prodotto su richiesta? o un servizio di dominio per recuperare un prodotto da un asset?

class Asset
{
    public function getProduct(ProductType $productType, aDAO $dao){

    }
}

Aggiornamento: l'asset non può avere un prodotto duplicato

    
posta Moon 28.03.2017 - 11:23
fonte

1 risposta

2

In tali situazioni, mi chiedo se la logica o il modello di business siano corretti, non quello che ho implementato o ciò che è meglio per il software. Un'altra cosa che è importante per Aggregate e DDD è il linguaggio e l'implementazione ubiquitaria secondo la logica aziendale, non ciò che è meglio in senso software. Quindi sono permessi cose come copiare / incollare in DDD (ovviamente, questo è un argomento vasto e non dovrebbe essere preso alla lettera).

Ciò che mi lascia perplesso è la seguente frase:

When a user uploads an image and information on the image, my app creates products based on the image.

Dici che il prodotto è stato creato sulla base delle informazioni inserite con l'immagine. Quindi, un utente inserisce un'immagine e alcune informazioni su di esso e sulla base di queste informazioni si creano prodotti. Come ho capito, Asset non si basa sui prodotti ma sulle informazioni contenute nelle immagini. Inoltre, non penso davvero che i prodotti non condividano le stesse informazioni o immagini. Quindi è più di una relazione molti a molti basata su informazioni e, probabilmente, le informazioni possono essere interconnesse con più immagini.

Come hai detto tu, gli aggregati definiscono il limite della transazione. In tal caso puoi porsi una domanda di logica aziendale (irrilevante di come l'hai implementata)

If I delete an Asset, MUST all related products be deleted as well? Are these products independent from other Entities?

Se la risposta è sì, chiediti se il modello è corretto, hai davvero implementato il modello in base alla logica di business. Vai alle radici, la logica aziendale definita dall'esperto del dominio e dagli uomini d'affari, non ciò che è attualmente implementato.

    
risposta data 28.03.2017 - 14:51
fonte

Leggi altre domande sui tag