Pattern del repository con oggetti complementari (aggregati)

4

Rifattorizzare una vecchia API in una nuova, a causa di diversi strumenti che la utilizzano (admin e alcuni script di manutenzione) e la compatibilità con le versioni precedenti, la struttura del database deve rimanere invariata.

Ho una tabella utente e un'altra tabella user_optionals correlata 1: 1. user_optionals sono solo alcuni campi con alcune opzioni extra impostate dall'utente .

Questo, nella mia app, è attualmente riflesso da un utente e da un modello UserOptional .

Quindi sto usando il modello di repository, ognuno ha il suo repository, UserRepository e UserOptionalRepository .

Sono un po 'preoccupato di dover iniettare e gestire due diversi repository nei miei servizi in quanto UserOptional non esiste se il suo utente in precedenza non lo fa .

Ho letto e sembra adattarsi a un concetto di sviluppo basato sul dominio noto come Agregate, ma non sono ancora sicuro su come gestirlo.

Quindi mi chiedo se dovrei applicare qualsiasi schema o metodologia qui che agisce su entrambi. Forse raggruppando entrambi su un Modello univoco o creando un nuovo repository composto da UserRepository e un UserOptionalRepository , forse lo sto pensando troppo ...

    
posta vivoconunxino 10.08.2018 - 11:29
fonte

1 risposta

3

È normale (ma non obbligatorio) che gli aggregati si estendano su più tabelle nel tuo database.

Se le entità UserOptional sono subordinate alle entità User - se non vengono riassegnate da un utente a un altro, se il ciclo di vita di un UserOptional è all'interno del ciclo di vita di un Utente, se c'è un invariant che si estende su più UserOptional all'interno dello stesso utente ... quindi può avere senso avere un "aggregato" che includa sia l'entità User che le relative entità UserOptional.

L'entità Utente nel tuo modello di dominio probabilmente fungerà da "radice aggregata".

Un euristico da considerare - è necessario supportare modifiche simultanee di UserOptionals che sono collegati allo stesso utente?

Gli aggregati sono, in effetti, un blocco a grana grossa che garantisce che le modifiche ai dati entro i confini del l'aggregato avviene uno alla volta. Se questo vincolo introdurrà troppe contese per i tuoi casi d'uso, potrebbe essere necessario considerare UserOptional come un aggregato distinto che rappresenta.

    
risposta data 13.08.2018 - 14:20
fonte

Leggi altre domande sui tag