Mantenimento di un ID univoco per un numero di entità

Question

Mantenimento di un ID univoco per un numero di entità

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

3

Descrizione:

Dato un portale di aggregazione, l'utente deve essere in grado di creare, leggere e aggiornare l'entità richiesta. L'entità qui è di diversi tipi e vive in sistemi diversi. Il portale mostra la metrica delle entità in una determinata unità di tempo e consente a un utente di filtrare i dettagli per tipo, nome, ecc. Il sistema è fondamentalmente un sistema basato sul ticketing dove l'utente deve prima creare un biglietto per ogni richiesta (es. crea, modifica e cancella).

L'utente può avere diversi ruoli, ad esempio: utente, amministratore e responsabile del team, ecc. L'utente può creare, modificare ed eliminare (solo prima della cancellazione e della fase risolta).

Esempio:

Dato che ci sono quattro diversi tipi di entità Bag, Car, Oven e Apple. Hanno tutti un proprio sistema esterno, il mio sistema dovrebbe consentire all'utente di creare queste risorse (che alla fine delega le richieste al sistema originale), filtrarle in base al loro tipo, modificarle ed eliminarle. Il sistema dovrebbe essere responsabile di tenere traccia di ogni richiesta.

                         Resolved
                        /
                       /
   New --- Waiting ---
                       \
                        \
                         Cancelled

Problema:

Al momento tutti i sistemi esterni hanno la loro nozione di ID univoco ea volte non ad esempio una mela ha un nome Foo nella casella A, ma un'altra casella B potrebbe avere una mela con lo stesso nome.

In secondo luogo, il sistema Apple potrebbe decidere di spostare Apple Foo in qualche altra casella Z, come potrei sapere che la mela Foo nella casella Z è la stessa mela?

Quindi, fondamentalmente sto cercando di definire un ID univoco per ogni risorsa nel mio sistema che potrebbe essere collegato con entità in sistemi esterni.

Spero che la domanda sia chiara perché ho cercato di tagliare la descrizione e la domanda in quanto fanno parte di un dominio più complesso.

PS: sono nuovo nel design basato su domini, quindi per favore indicami i riferimenti appropriati mentre usi i termini chiave.

object-oriented domain-driven-design object-oriented-design

posta CodeYogi 09.09.2017 - 10:34

fonte

2 risposte

0

At present all the external systems have their own notion of unique ID and sometimes not for example an apple has a name Foo in box A but another box B may have an apple with same name.

Se fosse tutto ciò di cui ti occupavi, sarebbe facile. Basta concatenare l'ID della casella con l'ID entità e sapresti che:

A::Foo != B::Foo

Second, the Apple system may decide to shift Apple Foo to some other box Z, how could I know that the apple Foo in box Z is same apple?

Questo è ciò che rende difficile. Perché ora:

A::Foo == Z::Foo

So, basically I am struggling to define unique ID for each resource in my system which could be linked with entities in external systems.

Puoi estrarre la tua mela per identificatori univoci o puoi utilizzare il fatto che ti è consentito modificare la mela e dire alla mela:

risposta data 10.09.2017 - 06:46

fonte

Leggi altre domande sui tag object-oriented domain-driven-design object-oriented-design

Dove dovrebbe un QC all'interno della squadra eseguire i test in uno scenario di ramificazione delle funzionalità? Qual è il modo migliore di utilizzare swift 4 / iOS per gestire richieste asincrone es. al database Firebase? [chiuso]

score 2 · Accepted Answer

Ipotesi

Per riassumere, il tuo sistema si occupa di entità che dovrebbero essere create e possedute da altri sistemi e devi monitorare la loro identità attraverso il panorama del sistema.

Non mi è chiaro se il tuo sistema funziona all'interno di un singolo dominio più grande, o se il tuo sistema fa fronte a un suo sottodominio coerente, che è relativamente indipendente dagli altri (ticketing). Prenderò in considerazione quest'ultimo, quindi ragioneremo nel tuo contesto limitato .

ID proprio o non proprio ID? Questa è la domanda

Nel tuo contesto limitato, dovresti identificare le entità che il tuo sistema di ticketing deve gestire:

ENTITY: An object fundamentally defined not by its attributes, but by a thread of continuity and identity. -- Eric Evans in Domain Driven Design

La tua domanda suggerisce che non esiste un unico sistema di riferimento autorevole che possa definire univocamente l'ID di un'entità attraverso il paesaggio. Quindi sembra ragionevole gestire il tuo ID univoco per tracciare l'identità dei tuoi oggetti.

Gestione del link

Qualsiasi entità locale è correlata a una o più entità estere gestite all'interno degli altri sistemi. Queste entità estranee (definite da un ID di sistema estraneo e da un'entità di entità estranea) non hanno alcun significato nel contesto limitato senza essere associate alla propria entità locale che funge da colla. Quindi le entità estranee dovrebbero appartenere a un aggregato a cui la tua entità locale sarebbe la radice aggregata:

AGGREGATE: A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the AGGREGATE, designated as the root. A set of consistency rules applies within the AGGREGATE’S boundaries.
-- Eric Evans in Domain Driven Design

Mappatura degli oggetti

Ora la parte difficile sarà la mappatura del tuo oggetto: come identificare l'identità degli oggetti attraverso il paesaggio? Quando è Foo in Z la stessa mela di Foo in A? Quando Foo in B è una mela diversa da Foo in A, Quando è Foo in A uguale a 123 in C?

Quattro opzioni:

o hai un set di caratteristiche che identificano univocamente uno stesso oggetto: ad esempio Martin Smith nato il 1/2/63 a Parigi può essere identificato sulla base di queste 4 informazioni con un'alta probabilità su sistemi diversi, anche se utilizzare diversi ID come numero di sicurezza nazionale, numero di passaporto, numero cliente o numero di dipendenti. In questo caso, puoi con le query appropriate creare il tuo mapping ogni volta che ne hai bisogno,
o hai almeno sottoinsiemi comuni di dati di entità che possono aiutare a far corrispondere la stessa identità di due entità in due sistemi in un momento specifico nel tempo.
o gli altri sistemi devono contribuire alla creazione di mappe. Ciò potrebbe essere realizzato ad esempio attraverso architettura guidata dagli eventi , in cui i sistemi che creano o trasferiscono entità inviano messaggi che verrebbe consumato dal tuo sistema per rimanere sincronizzato.
o un mix di quanto sopra

Tutto ciò presuppone ovviamente che le entità siano oggetti che hanno realmente un'identità, e non "anonimi" valore oggetti , la cui identificazione non ha molta importanza.

Mappatura del contesto di delimitazione

Infine, e dal punto di vista della modellazione del dominio, sarebbe opportuno mantenere una mappa di contesto , che le mappe il tuo modello di dominio del tuo contesto limitato, al modello di dominio di altri contesti limitati.