Comunicazione inventario, prezzi e catalogo prodotti

Question

Comunicazione inventario, prezzi e catalogo prodotti

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

1

Immagina di creare un'applicazione per e-commerce. Per semplicità, descriverò solo 3 contesti limitati. 1. Catalogo prodotti: è responsabile della manutenzione delle descrizioni dei prodotti, delle caratteristiche e così via 2. Prezzi: è responsabile per i prezzi dei prodotti 3. Inventario: è responsabile della gestione delle scorte. Se un prodotto è disponibile o meno.

Quindi, quando un cliente entra nel sito e-commerce, vorrei mostrare i prodotti. Per questo ho bisogno di avere il prezzo e ancora bisogno di sapere che se abbiamo il prodotto in magazzino.

Quindi qual è il modo migliore per farlo? 1.Un approccio è il catalogo dei prodotti solo effettuare richieste sincrone per inventario e prezzi. 2. Secondo approccio è quello di mantenere le informazioni sui prezzi e se il prodotto ha in magazzino sul catalogo prodotti BC. Pertanto, ogni volta che viene modificato un prezzo nel Contesto dei prezzi, esso aumenta e l'evento e il Catalogo prodotti possono aggiornare queste informazioni. Allo stesso modo per il contesto di inventario.

Preferisco il secondo approccio, ma sembra che io stia replicando le informazioni, ad esempio prezzo e disponibilità.

Pensieri?

domain-driven-design event-sourcing

posta p.magalhaes 02.04.2018 - 06:55

fonte

4 risposte

Leggi altre domande sui tag domain-driven-design event-sourcing

Approccio all'architettura per lo sviluppo di un'applicazione generatore XML A seconda delle dipendenze

score 1 · Answer 1

Cercherò sicuramente di evitare l'opzione n. 1. Le dipendenze sincrone tra i servizi sono un anti-pattern e complicano le operazioni.

La replica delle informazioni non è una cosa negativa di per sé, quando c'è un produttore e consumatori chiari. Anche se dovrebbe essere mantenuto il più basso possibile, non avrei problemi a replicare i dati.

Il punto è che, quando altri servizi potrebbero essere scaricati o sovraccarichi, la pagina del prodotto continuerà a funzionare. Questa è una buona cosa che probabilmente vuoi per un sito di e-commerce.

Il lato negativo è che le informazioni su quella pagina potrebbero essere un po 'obsolete. Normalmente non è un problema, poiché vedrai le informazioni esatte quando passerai da "browsing" a checkout reale, che dovrebbe essere un'altra applicazione con i dati "master".

Ovviamente c'è sempre la terza opzione, per provare a riorganizzare i limiti del servizio in un modo che non richiede che molti dati vengano replicati.

score 0 · Answer 2

Non mi piace 2. Sono contrario alle variazioni di prezzo che devono propagarsi nella descrizione del prodotto. Preferirei avere il prezzo, la disponibilità e la descrizione alzati ogni volta che qualcuno voleva un rapporto su un prodotto. Tale rapporto attingerà a tutti e tre i contesti limitati, riceverà il timestamp e non sarà mai aggiornato. Sarà sostituito quando richiesto nuovamente.

score 0 · Answer 3

Hai un altro dominio: il sito web o l'applicazione mobile, ovvero la presentazione. Questo può agire come un contesto Limitato, con i suoi modelli di lettura, che si basano sui modelli dell'altro contesto limitato. Non ha regole commerciali da scrivere per proteggere.

La presentazione continua ad agire come una cache locale, un livello di integrazione. Se il tuo sistema è basato su eventi, puoi utilizzare gli eventi per mantenerlo aggiornato.

So whats is the best way to do that? 1.On approach is the Product Catalog just make synchronous requests to Inventory and Pricing. 2. Second approach is to maintain the price information and if the product has in stock on the Product Catalog BC

Cerca di mantenere puliti i 3 contorni limitati, dovrebbero avere modelli indipendenti, quindi non mescolarli.

Un altro modo per integrarli è quando un cliente effettua un ordine. In quel processo vengono utilizzati tutti e 3 i contesti limitati, ma non conosci l'uno dell'altro, si utilizza un Process manager / Saga per gestire il processo a lungo termine. Questa è un'integrazione per il lato scrittura / comando del tuo sistema.

score 0 · Answer 4

Cercherò di evitare entrambi gli scenari: un BC fa richieste sincrone all'altra e inquina i dati di una BC con i dati dell'altro.

Hai due opzioni principali:

Mantieni una presentazione leggendo il modello con i dati pronti per la visualizzazione (probabilmente una singola tabella denormalizzata, per le migliori prestazioni).
Utilizza un'interfaccia utente composita. L'interfaccia utente effettua diverse chiamate per costruire l'intera pagina (catalogo, prezzi, scorte, promozioni, ecc.)

Inoltre, dovresti considerare la funzione "cerca". Alla fine, se hai un catalogo molto grande, probabilmente avrai un modo complesso per cercare prodotti. Ciò significa che avrai bisogno di tutti i dati ricercabili (prodotti con magazzino, prodotti con un determinato intervallo di prezzo, ecc.) In un indice di ricerca. A seconda di come si costruisce questo sistema di ricerca, potrebbe funzionare come un modello di lettura completa (il risultato della ricerca contiene tutte le informazioni necessarie per costruire la pagina) o si finirà con un'interfaccia utente composita (il risultato della ricerca deve essere arricchito effettuando chiamate a più BC.

Come nota finale, la composizione dell'interfaccia utente può essere eseguita in 2 posizioni: direttamente dal client o creando un'API dedicata che chiama gli altri BC e crea un DTO per la pagina specificata. Questa seconda opzione potrebbe funzionare meglio se si evitano più chiamate remote, ma potrebbe richiedere un'implementazione diversa per ogni client (mobile, web, desktop) poiché ogni pagina del client potrebbe avere esigenze diverse.