Come creare atomicamente una nuova entità in più contesti senza accoppiamento?

Question

Come creare atomicamente una nuova entità in più contesti senza accoppiamento?

#1 da (4 voti)

1

Supponiamo che ci siano più contesti con la stessa entità logica ma con differenti nozioni. La creazione di una tale entità dovrebbe avere l'effetto collaterale che in tutti gli altri contesti dovrebbe essere creata la stessa entità logica.

Lo faccio semplicemente inviando un evento di dominio che contiene tutti i campi obbligatori per tutti i contesti. Il problema è che il contesto che inizialmente crea la nuova entità è strettamente collegato a tutti gli altri contesti in quanto deve creare l'evento di dominio corretto con tutti i campi richiesti da altri contesti. Come rimuoverò quell'accoppiamento?

Esempio

Diciamo che per un software di gestione della formazione ho scoperto i contesti Finanza e Formazione. Entrambi i contesti condividono l'entità logica Studente. Mentre in Finanza uno studente ha un numero IBAN, in Formazione questa informazione è inutile.

Ora voglio implementare il caso d'uso "Registrati studente". Questa registrazione dovrebbe essere atomica, cioè l'entità dovrebbe esistere in tutti i contesti. In realtà ho quindi creato un ulteriore contesto di registrazione. Ora sono preoccupato che il contesto che inizialmente crea l'entità abbia bisogno di conoscere i dettagli di ogni altro contesto su questa entità.

Questo in qualche modo si scontra con l'idea che un contesto dovrebbe creare un modello coesivo. In questo caso Insegnamento e finanza sono coerenti, ma la registrazione non lo è. E non importa dove sposterei la creazione di quell'entità, sono sempre accoppiata ad altri contesti.

Supponiamo che cambierò l'entità nel contesto finanziario aggiungendo un ulteriore campo per es. credito. Ora devo toccare Finanza e il contesto di registrazione.

Vedi un modo per evitare quell'accoppiamento?

domain-driven-design

posta Markus Malkusch 22.05.2016 - 22:30

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design

Come funziona jQuery? Posso revocare la licenza del progetto dopo aver tradotto il suo codice?

score 4 · Accepted Answer

Penso che tu stia parlando di più contesti limitati che parlano tutti della stessa entità concettuale, mentre ciascuno del contesto limitato ha responsabilità diverse attorno a quell'entità, quindi le diverse nozioni.

Per ciascun tipo di entità, uno dei contesti limitati dovrebbe avere la responsabilità fondamentale di essere autorevole; gli altri contesti possono riferirsi a quell'entità, anche se adornano con ulteriori informazioni sulle loro preoccupazioni.

Il contesto autorevole, per un tipo di entità, è l'unico autorizzato ad accettare e inserire una nuova entità di quel tipo nel sistema nel suo insieme; ad esempio, è il contesto che gestisce gli ID per quelle entità e responsabile dell'assegnazione di nuovi ID per le nuove entità. Ad esempio, l'assegnazione degli ID cliente o degli ID ordine. Gli altri contesti possono fare riferimento a queste entità per id.

Gli altri contesti non creano nuove entità per le quali non sono autorevoli, ma si riferiscono a coloro che vogliono creare nuove entità alla fonte autorevole. Il contesto autoritativo può quindi inviare messaggi di eventi che indicano la creazione (aggiornamento / cancellazione, se necessario) di nuove entità negli altri contesti, possibilmente previo accordo (per esempio con una sottoscrizione).

Se non lo fai e consenti ai contesti indipendenti di accettare e inserire le stesse informazioni sull'entità, per assegnare nuovi ID per la stessa nuova entità, allora sei nel territorio di legare insieme i sistemi legacy usando Gestione dei dati anagrafici . In MDM, ogni sistema silente ritiene che sia autorevole per gli stessi tipi di entità, accettando, inserendo e assegnando la propria chiave primaria alla stessa entità. La preoccupazione di Master Data Management è quindi quella di mappare le chiavi primarie in un sistema silenziato a chiavi primarie gestite in un altro, occupandosi di problemi di qualità dei dati (ad esempio variazioni di nome tra un singolo cliente) e sovrapposizione di aggiornamenti allo stesso tempo. In pratica finisci con più insiemi di chiavi primarie per la stessa entità (uno per ciascuno dei sistemi di silos legacy che ritiene di avere l'autorità per il tipo di entità e, in genere, uno aggiuntivo per il sistema MDM stesso.)

C'è una tensione tra la nozione di studente con registrazione atomica (con tutte le informazioni per tutti gli altri contesti raccolti alla registrazione) e il desiderio di un accoppiamento libero tra i contesti. Penso che tu scelga l'uno o l'altro.

Probabilmente opterei per l'accoppiamento più sciolto e raccogliamo (e persistono) informazioni finanziarie (ad esempio credito) separatamente dalla registrazione. Penso che separa appropriatamente le preoccupazioni, e diversamente non c'è più merito nel separare i contesti.

La mia prossima scelta è che preferirei unire tutti i contesti in uno più di duplicazione dei dati di credito tra di loro.