Stiamo sviluppando un'applicazione in cui i provider possono offrire i loro prodotti e i consumatori possono comprarli (una sorta di marketplace). Cerchiamo di applicare i concetti DDD nella nostra progettazione del modello e l'implementazione segue uno stile microservizi. Ciò implica che i dati appartengono a un Contesto Limitato (BC) e solo i microservizi all'interno di quel BC possono accedervi. Al di fuori di questo BC, informazioni specifiche possono essere interrogate solo attraverso un'interfaccia pubblica del BC o sottoscrivendo eventi pubblicati da quel BC.
La mia domanda riguarda la progettazione degli ordini. Gli ordini sono posti dai consumatori e accettati e soddisfatti dai fornitori. Possono anche essere manipolati dal servizio clienti. Al momento un ordine contiene solo prodotti di un unico fornitore, ma in futuro potrei essere invitato a sostenere l'acquisto da più fornitori contemporaneamente.
Tutte le implementazioni che ho visto di sistemi simili contengono un singolo modello Order, che tende ad essere davvero gonfio di informazioni sui prodotti, il fornitore, il consumatore, la fatturazione, le consegne, i pagamenti, ecc. Sto cercando di evitare che , ma sto affrontando la domanda di "Chi possiede l'ordine"?
Posso pensare alle seguenti risposte:
- Esiste un contesto limitato agli ordini a cui si accede sia dal consumatore che dal fornitore. Ciò significa che l'API consumer ha un'operazione di Place Order che comunica con gli ordini BC e crea un ordine e l'API Provider ha un'operazione come Accept Order che parla agli stessi ordini BC e modifica lo stato di quello stesso modello di ordine.
- Esistono 2 ordini BC: Ordini consumatori e Ordini fornitori. L'API Consumer inserisce un ordine nel Consumer BC. Questo crea l'ordine e pubblica un ConsumerOrderCreatedEvent. Il ProviderOrders BC ascolta questo evento e crea un ordine locale (ProviderOrder) che fa riferimento a ConsumerOrder. Tramite l'API Provider, l'ordine può essere accettato, che pubblicherà un ProviderOrderAcceptedEvent, che consentirà a ConsumerOrders di contrassegnare l'ordine come accettato e informare il consumatore a riguardo.
Il mio approccio personale preferito è l'opzione 2 in quanto vedo diversi vantaggi (vedi sotto), ma non sono sicuro che valgano la complessità aggiunta.
Non posso formulare una domanda specifica, ma poiché questo problema deve essere stato risolto migliaia di volte, vorrei sapere se esiste un approccio preferito, una soluzione ben nota o un progetto di riferimento che possa aiutarmi.
Vantaggi dei contesti separati di ProviderOrders e ConsumerOrders:
- Un singolo ConsumerOrder può generare più ProviderOrders (se l'ordine contiene prodotti di più provider
- Il flusso di lavoro di un ProviderOrder potrebbe essere diverso / più complesso rispetto al flusso di lavoro di un ConsumerOrder.
- Sia il consumatore che il fornitore devono vedere la cronologia degli ordini, che immagino come una tabella denormalizzata per letture veloci, ma entrambe le cronologie degli ordini contengono dati diversi (ad esempio gli ordini dei consumatori contengono informazioni sui provider e gli ordini dei fornitori contengono informazioni sui consumatori) e sono interrogato in modo diverso (dal consumatore e dal fornitore). Questo può essere implementato in un'unica tabella, ovviamente, ma sembra più pulito se si tratta di 2 tabelle dedicate a un unico scopo.
- Isolamento dati / partizionamento. Gli ordini cliente sono sempre accessibili dall'ID consumatore, gli ordini fornitore sono sempre accessibili da ProviderId.
Ho una conversazione molto interessante su questo argomento in un forum separato, quindi ho pensato di collegarlo qui, nel caso qualcuno volesse leggere più pensieri su questo argomento. La stessa domanda sul forum di discussione di NServiceBus
Nota: è implementato in .NET, da più team, da più repository e soluzioni Visual Studio, ospitato in un cluster di Service Fabric e utilizzando NServiceBus per la messaggistica.