Ho un sistema che interagisce con un'API REST come origine dati. Questo sistema è basato su DDD e tutti i miei modelli attuali sono modelli CRUD. Esiste un modello che l'API REST è in grado di interrogare solo come aggregato completo, ma è in grado di scrivere solo come entità all'interno dell'aggregato. Il ragionamento alla base del design di questa API è che la scrittura di qualsiasi entità nell'aggregato cambierà lo stato del resto delle entità.
Questa mi è sembrata una buona opportunità per provare una derivata di CQRS in cui ho un aggregato di lettura che viene popolato da quella query all'API REST e una serie di aggregati di scrittura più piccoli (ognuno di questi corrisponde a un'entità nell'aggregazione di lettura .)
Usando il modello del mediatore ogni scrittura potrebbe innescare un evento. Questo evento a sua volta fa sì che il repository di lettura aggregata riesamini nuovamente l'API REST.
Il modello di lettura non è così complesso, ma penso che sia qui che la mia comprensione del CQRS si rompe ...
Asserzione: quando istanzio un modello di scrittura, deve avere tutte le proprietà dell'entità corrispondente nell'aggregazione di lettura. Quindi posso usare setter sul modello di scrittura per manipolare il suo stato e infine inviarlo al data mapper per essere persistito e inviare il mio evento di aggiornamento del modello letto.
Domanda 1: Che cosa utilizzo per popolare il modello di scrittura sulla sua istanza? Il mio pensiero immediato è stato quello di creare un mapper che traduca la corrispondente entità di lettura aggregata nel modello di scrittura.
Domanda 2: Poiché i modelli di scrittura e il modello di lettura avranno le stesse proprietà e solo metodi diversi (solo i getter nel modello di lettura e solo i setter nel modello di scrittura) i loro costruttori dovrebbero rimanere carini praticamente uguale. Posso quindi riutilizzare le stesse fabbriche? Questa è una decisione appropriata?