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).