È possibile che si desideri visualizzare il livello di inventario sulla pagina Web oppure visualizzare il numero di edizione dell'inventario in magazzino (immaginando che l'inventario sia costituito da libri, riviste, ecc.). Questa informazione proviene dal dominio di Inventory.
La cosa principale da notare a questo punto è che stai parlando di una vista, vale a dire che l'uso di dati non aggiornati è accettabile.
Detto questo, non è necessario interagire con gli aggregati (che sono responsabili della prevenzione delle modifiche che violano l'invariante aziendale), ma con una rappresentazione di una copia recente dello stato dell'aggregato.
Quindi quello che mi aspetterei normalmente è una query eseguita sul Catalogo prodotti, un'altra eseguita sull'Inventario e qualcosa per comporre i due nel DTO di cui hai bisogno per supportare la vista.
Caricare sia il dominio del prodotto che gli aggregati del dominio dello spazio pubblicitario?
Quindi è vicino . Non abbiamo bisogno di caricare gli aggregati, perché non cambieremo nulla. Ma abbiamo bisogno del loro stato; così potremmo caricarlo. Detto questo, normalmente mi aspetto che i due domini vengano eseguiti in processi diversi. Pertanto, chiameremmo entrambi, non caricando entrambi.
Conservereste alcune proprietà sull'entità del dominio del prodotto per il numero in stock e l'edizione in stock, quindi usereste gli Eventi di dominio per aggiornarli quando l'entità Inventory viene aggiornata?
"Non attraversare i corsi d'acqua. Sarebbe male."
Utilizzare gli eventi per coordinare le informazioni nei contesti di dominio: ottima idea. Spingere concetti che appartengono a un dominio in un altro: opposto di una grande idea, tranne che di più.
Vuoi mantenere puliti i domini. Le applicazioni che interagiscono con i domini non sono così importanti. 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 vice versa.
Non conosco alcun motivo per cui una singola applicazione deve essere limitata a un singolo dominio. Finché esiste un'unica fonte di verità, puoi distribuire le transazioni nel modo che preferisci.
Ma solo per pensarci bene, nell'esempio sopra finiremmo con potenzialmente 2 tabelle DB per il catalogo dei prodotti e l'inventario dei prodotti. Ora, usiamo lo stesso identificatore in questi in quanto è lo stesso prodotto.
Sarebbe il modo più semplice. In termini più grandi, si utilizza lo stesso identificatore perché l'entità del mondo reale è la stessa; i due diversi contesti limitati modellano quell'entità in modo diverso, ma il modello non è l'entità del mondo reale.
Quando non funziona, avrai bisogno di alcune query da utilizzare per colmare il divario. Penso che la variante più comune di ciò sia che l'entità più recente conserva l'id dell'entità più vecchia. Lo vedrai anche all'interno di un singolo BC: i candidati, una volta approvati, diventano clienti. È un aggregato diverso (lo stato associato a un client è soggetto a un invariante diverso da quello del richiedente); quindi se il livello di persistenza utilizza 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".
Oppure, potremmo usare 1 tabella e 1 riga di tabella per i dati e semplicemente mappare i dati rilevanti sulle proprietà aggregate?
YIKES! No, non farlo. Stai aggiungendo il conflitto di transazione senza alcun motivo commerciale per farlo.