Progettazione guidata da domini e interazione tra domini

6

Sono un neofita del DDD relativo, ma sto leggendo qualsiasi cosa e tutto quello che posso mettere le mani su per bollire e distillare le mie conoscenze.

Mi sono imbattuto in questa domanda DDD e una delle risposte mi ha incuriosito.

Contesti e amp; Domini?

In una delle risposte il poster fornisce l'esempio di un sistema di e-commerce con prodotti che si trovano in almeno 2 domini:

1) Catalogo prodotti 2) Gestione inventario

OK, tutto ha senso, cioè nel tuo e-commerce ti interessa mostrare le informazioni sul prodotto e non interessarti alla gestione dell'inventario.

MA. È possibile che si desideri visualizzare il livello di inventario sulla pagina Web o si desideri visualizzare il numero di edizione dell'inventario in magazzino (immagina che il tuo inventario sia libri, riviste ecc.). Queste informazioni provengono dal dominio Inventario.

Quindi, come gestiresti questo? Vuoi

a) Caricare sia il dominio del prodotto che gli aggregati del dominio inventario? b) Saresti in possesso di alcune proprietà sull'entità del dominio del prodotto per il numero in magazzino e l'edizione in magazzino, quindi utilizzare gli eventi del dominio per aggiornarle quando l'entità dello spazio pubblicitario viene aggiornata?

Un'ultima domanda. So che intendiamo dimenticare / ignorare la persistenza del dominio e pensare al dominio. Ma solo a pensarci, nell'esempio sopra avremmo finito con potenzialmente 2 tabelle DB per il catalogo prodotti e l'inventario dei prodotti. Ora, usiamo lo stesso identificatore in questi in quanto è lo stesso prodotto. Oppure, potremmo usare 1 tabella e 1 riga di tabella per i dati e semplicemente mappare i dati rilevanti sulle proprietà aggregate?

    
posta PendorPaul 01.02.2016 - 11:37
fonte

4 risposte

4

You may want to display the inventory level on the web page, or you may want to display the edition number of the inventory in stock (imagine your inventory is books, magazines etc). This information comes from the Inventory domain.

La cosa principale da notare a questo punto è che stai parlando di una visualizzazione, il che significa che l'utilizzo di dati obsoleti è accettabile.

Detto questo, non è necessario interagire con gli aggregati (che sono responsabili di impedire che le modifiche violino l'invarianza di business), ma con una rappresentazione di una copia recente dello stato dell'aggregato.

Quindi quello che mi aspetterei normalmente è una query eseguita contro il catalogo prodotti e un'altra esecuzione contro l'inventario, e qualcosa da comporre i due nel DTO che è necessario supportare la vista.

Load both the Product domain and the Inventory domain aggregates?

Quindi chiudi . Non abbiamo bisogno di caricare gli aggregati, perché non cambieremo nulla. Ma abbiamo bisogno del loro stato; quindi potremmo caricarlo. Detto questo, normalmente mi aspetto che i due domini funzionino in processi diversi. Pertanto, chiameremmo entrambi, non caricando entrambi.

Would you hold some properties on your Product domain entity for number in stock, and edition in stock, and then use Domain Events to update these when the Inventory entity is updated?

"Non attraversare i flussi. Sarebbe male."

Uso degli eventi per coordinare le informazioni tra contesti di dominio: idea di grande . Spingere concetti che appartengono a un dominio in un altro: opposto a una grande idea, eccetto di più.

Vuoi mantenere puliti i domini. Le applicazioni che interagiscono con i domini, non è così importante. Quindi, ad esempio, è ragionevole che l'applicazione Inventory chiami un servizio nell'applicazione del prodotto per interrogare alcuni concetti specifici del prodotto da aggiungere a una vista. O viceversa.

Non conosco alcun motivo per cui una singola applicazione debba essere limitata a un singolo dominio. Finché esiste un'unica fonte di verità, puoi distribuire le transazioni in qualsiasi modo.

But just to think this through, in the example above we would end up with potentially 2 DB tables for product catalog and product inventory. Now, do we use the same identifier in these as it's the same product.

Questo sarebbe il modo più semplice. In termini più ampi, si utilizza lo stesso identificatore perché l'entità del mondo reale è la stessa; i due diversi contesti limitati model quell'entità in modo diverso, ma il modello non è l'entità del mondo reale.

Quando non funziona, avrai bisogno di una query da utilizzare per colmare il divario. Penso che la variazione più comune di questo è che la nuova entità conserva l'id dell'entità più vecchia. Lo vedrete anche in un singolo BC: i candidati, una volta approvati, diventano clienti. È un aggregato diverso (lo stato associato a un cliente è soggetto a una diversa invarianza rispetto a quella del richiedente); quindi se il livello di persistenza sta utilizzando i flussi di eventi, il flusso per il nuovo aggregato avrà bisogno di un identificatore diverso. Quindi ci sarà un po 'di stato da qualche parte che dice "questo candidato è diventato questo cliente".

Or, could we use 1 table and 1 table row for the data and simply map the relevant data onto the aggregate properties?

YIKES! No, non farlo. Stai aggiungendo la contesa per le transazioni senza alcun motivo commerciale per farlo.

    
risposta data 01.02.2016 - 17:17
fonte
1

DDD è pensato per le applicazioni in cui la logica aziendale è complessa. "stampare qualcosa" non è una logica aziendale complessa. In realtà non è affatto una logica aziendale.

Se la logica aziendale in un contesto ha bisogno di alcune informazioni per gestire correttamente alcuni casi d'uso, allora quell'informazione è parte di quel contesto. Quindi l'idea che un contesto limitato possa aver bisogno di informazioni disponibili in diversi contesti limitati non ha senso, perché il contesto limitato ha tutte le informazioni di cui ha bisogno.

    
risposta data 01.02.2016 - 12:36
fonte
1

Penso che la tua domanda richieda davvero 2 serie ortogonali di opzioni -

  • Carichi due oggetti e presenti i loro dati insieme o carichi 1 oggetto che contiene tutto ciò che vuoi?

  • Utilizzi aggregati per la visualizzazione di materiale o qualcos'altro?

Se credi nell'approccio CQRS, risulta che gli aggregati potrebbero non essere la soluzione migliore per le letture. Ogni volta che carichi un aggregato, se visualizzare i suoi dati o modificarli, aggiungi simultaneità e contesa al tuo sistema. Inoltre, gli aggregati sono potenzialmente più ingombranti e più lenti da caricare rispetto a quando si utilizzano modelli di lettura ad hoc su misura per la visualizzazione.

La soluzione a) dal tuo Q sembra soggetta a molte di queste insidie. L'opzione b) può essere valida, ma la utilizzerei solo se sono necessari i dati di InventoryManagement BC per applicare gli invarianti quando si modifica l'aggregazione Product . È meglio se un aggregato contiene tutti i dati necessari per verificare le sue regole di business dopo la modifica, ma dal lato della lettura possono sedersi ovunque.

Per quanto riguarda i dati, una raccomandazione comune è fornire a Bounded Contexts il proprio database (per motivi di deployabilità e SoC). Probabilmente dovrai usare gli stessi identificatori se vuoi abbinare i prodotti tra i due BC.

A proposito di interazioni BC incrociate, potresti anche dare un'occhiata a link

    
risposta data 01.02.2016 - 14:28
fonte
1

Dal mio punto di vista ci sono diverse definizioni di "Prodotto" - ogni contesto di delimitazione ha una sua definizione di "prodotto": dominio:

  • Nel Content-Management-Bounding-Context un prodotto ha un'immagine e un testo descrittivo.
  • In Inventory-Bounding-Context un prodotto ha quantità di stock, venditore di prodotti, forcasts quando il prodotto sarà disponibile
  • Nel Costo-Caculation-Contesto-contesto ci sono delle regole quanto un prodotto può costare per quantità.

In aggiunta a questi vorrei aggiungere un Shop-Bounding-Context con la sua definizione di prodotto (una combinazione pertinente dei domini del prodotto degli altri contesti di delimitazione).

Un prodotto-negozio avrebbe "immagine e un testo descrittivo" da contenuto e disponibilità da "Spazio pubblicitario" ma non da "venditore di prodotti" dall'inventario.

Questo ulteriore contesto di Shop-Bounding dipende dal contenuto, dallo spazio pubblicitario, dal prezzo di Bounding-Context

    
risposta data 01.02.2016 - 14:33
fonte

Leggi altre domande sui tag