ottiene l'ID aggregato in base ai suoi dati in esso

Question

ottiene l'ID aggregato in base ai suoi dati in esso

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

1

Ho una radice aggregata chiamata SizeRangeAggregate che contiene l'intervallo di dimensioni della dimensione del pezzo di abbigliamento e il prezzo per quell'intervallo. Ho creato un'API post rest che crea nuovo SizeRangeAggregate. Segue il CQRS / ES che significa

crea CreateSizeCommand
pubblicalo su CreateSizeCommand gestore di comandi
genera SizeRangeCreated evento
mantiene l'evento nello storestore
pubblica l'evento su SizeRangeCreated gestore di eventi in cui viene generato il modello di lettura chiamato SizeRangeReadModel

Voglio aggiungere una semplice logica di dominio in cui un'API non creerà un nuovo SizeRangeAggregate se l'intervallo è già definito in un altro SizeRangeAggregate.

Attualmente sto usando il filtro dell'intervallo di modello letto (qualcosa come getByRange) nel controller API per ottenere SizeRangeReadModel se esiste, prima di creare CreateSizeCommand . Ma penso di sbagliarmi perché si tratta di una logica di dominio e questo è il motivo per cui non dovrebbe essere nel controller.

Potresti suggerirmi la migliore opzione / modo per implementarlo.

domain-driven-design cqrs event-sourcing read-model

posta Vikas Kumar 02.10.2018 - 11:45

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design cqrs event-sourcing read-model

Come rappresentare un insieme di effemeridi? Come ottenere i messaggi SNS AWS nel bus di servizio di Azure

score 0 · Answer 1

But I think I am doing it wrong as this is a domain logic and thats why should not be in controller

Sebbene sia una logica di dominio, è un requisito che riguarda più Aggregati, quindi un servizio è il posto in cui inserire il codice. Tuttavia, questo requisito aziendale viene implementato principalmente utilizzando la tecnologia / infrastruttura, pertanto la logica del dominio può essere implementata con un codice semplice simile a questo:

if(repository.theAggregateDoesNotYetExist(some, data))
    sendCommand(createAggregate)

La soluzione più semplice è inserire questo codice nel servizio Applicazione che normalmente invia il comando.

Lo faccio in un altro modo. Il mio framework CQRS ha il concetto di validatori di comando. Questi sono componenti che intercettano i comandi e, se il contesto non li consente, li rifiutano. Non utilizzo i validatori di comandi per proteggere le regole aziendali che devono essere controllate all'interno degli aggregati. I validatori di comando sono anche alla fine coerenti, quindi non proteggono da inserimenti concorrenti. Insieme a una Saga possono finalmente portare l'intero sistema in uno stato consentito.

I validatori di comandi aiutano a seguire il principio Aperto-chiuso (puoi aggiungere tutte le regole aziendali desiderate senza modificare il codice esistente) e Principio di responsabilità singola (convalidano un solo comando per una singola regola aziendale).

Il modo in cui questo schema è implementato è decorando CommandDispatcher.

score 0 · Answer 2

I want to add a simple domain logic where an API will not create a new SizeRangeAggregate if the range is already defined in other SizeRangeAggregate.

Questo sembra un caso di Set Validation ; Greg Young recensisce bene i dettagli.

Parliamo di flussi di eventi come se fossero legati a un aggregato, ma la verità è che sono molto più vicini nella pratica a write ahead log di un database. Decidere che ogni aggregato ha il proprio stream è analogo a dire che ogni aggregato vive nel proprio database (logico).

(Se si considera un RDBMS, è facile vincolare tutte le righe di una tabella in un database, ma è molto più difficile applicare tale vincolo su due diversi database).

Se ogni aggregato ha il proprio stream univoco, non si verificherà la verifica di un vincolo sull'insieme di aggregati al momento della scrittura. Puoi utilizzare le visualizzazioni - copie di informazioni preparate leggendo da più stream come surrogato per un controllo assolutamente corretto, ma ci saranno condizioni di gara che porteranno a scritture conflittuali che dovrai risolvere in seguito.

All'interno del modello di dominio, questa vista sarebbe normalmente rappresentata come un servizio di dominio: fornirebbe un'API per farti sapere se un dato range è un univoco in un insieme di intervalli memorizzato nella cache e la logica del dominio potrebbe utilizzare tali informazioni.

Ma il rischio che la cache non sia più disponibile non scompare mai.

Ecco perché la domanda cruciale è

what's the cost to the business?

Se questa convalida è qualcosa di cruciale per l'azienda, allora hai bisogno di un modello di dominio che la supporti - e questo non è un modello in cui il set è distribuito in più parti indipendenti.