Tabelle dei codici di ricerca in DDD

0

Sono curioso del modo migliore per gestire i codici di tipo lookup che possono essere condivisi in contesti limitati. Ad esempio, codici di stato o codici di tipi aziendali specifici che potrebbero essere utilizzati in più contesti limitati. Ha senso avere un unico database per questi, con un'API in primo piano per recuperare gli elenchi di codici o duplicarli per ogni contesto limitato che ne ha bisogno? Inoltre, questo mi chiede cosa fare dell'integrità referenziale se si desidera la prima opzione. Molti dei codici non utilizzano una chiave naturale ma un id surrogato (generato automaticamente dal database).

    
posta user1560457 29.10.2018 - 22:18
fonte

2 risposte

2

DDD è ottimo ma non va più in alto che potrebbe. Sopra DDD possiamo immaginare ruoli aziendali che hanno responsabilità commerciali.

Una responsabilità aziendale di questo tipo è la gestione dei record come autorità di riferimento - ad es. se accettiamo un ordine, possiamo dargli un ID. C'è un certo dipartimento responsabile dell'accettazione o del rifiuto degli ordini, mantenendo l'elenco degli ordini come l'autorità di registrazione per loro, e nessun altro dovrebbe essere autorizzato ad accettare un ordine, emettere un ID ordine o dichiarare di essere l'autorità per il elenco degli ordini accettati.

Quindi, quando pensiamo a più contesti limitati, dovremmo cercare di capire che l'intenzione è di portare (manutenibile) l'automazione ai lavori dei vari ruoli aziendali e delle loro responsabilità commerciali - non semplicemente di separare le preoccupazioni al fine di affrontare l'automazione monolitica disegni.

...business-specific type codes that might be used in more than one bounded context.

Many of the codes aren't using a natural key but instead a surrogate (auto-generated by the database) id

Mantenere i tuoi codici commerciali è probabilmente una funzione aziendale di cui alcuni dipartimenti dovranno (o dovrebbero) essere responsabili. Dovresti fare domande su cosa accadrà se ogni contesto limitato mantiene la propria versione di questi codici? Un contesto limitato può aggiungere un codice che altri non hanno ancora aggiunto. È un problema? Esiste un dipartimento responsabile di questo (potrebbe essere IT, suppongo) e come si sentirebbero a mantenere i codici centralmente rispetto a tutti i contesti aziendali?

Does it make sense to have a single database for these, with an api in front to fetch the code lists, or duplicate them per each bounded context that needs them?

Stai chiedendo se fornire un'implementazione normalizzata dei codici o duplicarli in più contesti limitati.

Idealmente, dovremmo gestire questi codici in un unico posto. Come minimo, direi che potresti metterli in una cache in contesti limitati piuttosto che semplicemente duplicarli, e dovrebbero essere gestiti (quelli nuovi aggiunti, quelli vecchi obsoleti) centralmente.

Furthermore, this has me wondering what to do with referential integrity if the first option is desired.

Forse non dovresti eliminare i codici commerciali che sono potenzialmente usati da altri contesti limitati. Puoi invece renderli obsoleti e persino fornire un codice di inoltro o di sostituzione, questo come parte dell'API attorno alla gestione dei codici commerciali. Quindi, l'API parlerebbe di quali codici, intenzione commerciale, definizione del codice, politiche e amp; regole associate ai codici, lo stato di ciascun codice (corrente o meno) e quando non attuale: la / e sostituzione / i e / o chiarimenti (sottocodici preferiti).

    
risposta data 30.10.2018 - 01:41
fonte
0

Does it make sense to have a single database for these, with an api in front to fetch the code lists, or duplicate them per each bounded context that needs them?

Per i servizi autonomi, probabilmente vorrai memorizzare una copia di questi dati in ogni contesto che ne ha bisogno.

Dopodiché, il trade off è completamente giù. Usare lo stesso schema ovunque è "facile", ma potenzialmente spreca spazio. L'invalidazione della cache è uno dei due problemi difficili, quindi è necessario preoccuparsi di come verranno condivise le modifiche nei vari contesti.

Prestare attenzione al tasso di cambiamento: i codici di stato degli Stati Uniti sono rimasti stabili dal 1959; le unità di stockkeeping possono abbattere un bel po '.

what to do with referential integrity

L'integrità referenziale può essere uno spook show quando nuovi codici entrano nell'immagine, specialmente se possono apparire senza preavviso. Potrebbe avere più senso registrare i dati che altrimenti violerebbero i vincoli e notificare a un essere umano che sembra esserci un conflitto.

Ancora, cavalli per i corsi.

    
risposta data 30.10.2018 - 04:00
fonte

Leggi altre domande sui tag