È possibile che readmodel e writemodel ereditino dal modello per i campi in DDD + CQRS?

La condivisione di un modello base è contro tutto ciò che CQRS rappresenta. Se i tuoi modelli (scrittura e lettura) sono il 99% percento, allora è un'architettura CRUD dipinta per apparire come CQRS .

Devi dividere la scrittura dalla lettura perché i due modelli hanno comportamenti diversi: il modello di scrittura si occupa di garantire gli invarianti e il modello letto riguarda la lettura e la visualizzazione dei dati all'utente. È normale che alcuni campi siano condivisi ma solo come concetti. Nel lato scrittura, crei Commands che contiene quei campi, li invii ai modelli di scrittura ( Aggregates in DDD ) e generi events che ha alcuni campi da commands . Nella parte di lettura si legge events e si creano alcuni oggetti di persistenza semplici, senza alcun comportamento che garantisca gli invarianti; possono avere un comportamento ma un tipo diverso dai modelli di scrittura.

Dal lato della lettura si possono avere oggetti mega che contengono campi da più modelli di scrittura. L'idea principale dei modelli letti è molto veloce (cioè non JOINS ), quindi includi in row o document tutto ciò che ti serve per visualizzare i dati agli utenti.

Dall'altro lato, il lato di scrittura, hai inserito in commands solo le informazioni minime necessarie per mantenere il invariants (cioè ti riferisci ad altre radici Aggregate solo tramite i loro ID).

Quindi, come metafora, i modelli di scrittura e lettura sono come materia e antimateria: non dovrebbero collidere; sono separati (disaccoppiati) da eventi che agiscono come un campo magnetico.

UPDATE:

I modelli letti vedono solo gli eventi generati dagli Aggregati (i modelli di scrittura); non interrogano i modelli di scrittura in quanto è vietato; quindi i modelli di scrittura hanno solo command methods e nessun query methods ; d'altra parte, i modelli letti hanno solo query methods (cioè getters ) e nessun command methods ; i modelli letti sono immutabili; l'unico modo per mutate dei modelli letti è ascoltare events e applicarli events .

Is there any advice against having the fields (id, name, socialnumber, etc) of a relational database AND getters in a model then inherit them in WriteModel and ReadModel?

In realtà, c'è. Il modello di lettura e il modello di scrittura sono concettualmente diversi e, in particolare, si evolvono in modo ampiamente indipendente l'uno dall'altro.

Matthias Verraes ha scritto :

“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

Mi aspetto che i modelli di lettura e scrittura contengano molti concetti comuni. I tipi di valore del modello di dominio, ad esempio: se si dispone di un tipo Money , probabilmente avrà senso nel modello letto, proprio come nel modello di scrittura.

Tuttavia, come Constantin sottolinea , la motivazione per il modello CQRS è consentire alle scritture di utilizzare un sottostante struttura dati ottimizzata per le scritture (ad esempio: una cronologia) e legge una struttura dati sottostante ottimizzata per le letture. Quindi non avrei fretta di accoppiare il modello letto e scrivere il modello insieme.

I don't see how you're buying much from this except having immutable read objects. What purpose does that serve?

La chiarezza del codice è grande: mettere un riferimento a un'interfaccia immutabile nella firma del metodo indica chiaramente che non si sta tentando di modificare l'argomento in alcun modo. Pertanto, nei tuoi percorsi di codice di scrittura, non c'è confusione su quale oggetto verrà scritto: sarà sempre quello mutabile.