Come entrare in contatto con un altro Contesto Limitato senza l'API REST?

Eviterò la discussione sull'esistenza di due contesti limitati e sulla questione di come possono condividere i dati. Prima di farlo, tuttavia, devo sottolineare che ti stai rendendo un disservizio avendo 2 contesti limitati nello stesso processo. Dalla definizione di Microsoft

Bounded contexts are autonomous components, with their own domain models and their own ubiquitous language. They should not have any dependencies on each other at run time and should be capable of running in isolation. However they are a part of the same overall system and do need to exchange data with one another.

Un grande vantaggio dei contesti limitati è la loro indipendenza l'uno dall'altro. Se uno scende, l'altro dovrebbe sopravvivere ed essere in grado di continuare a funzionare. Ciò aiuta anche la scalabilità consentendo la distribuzione su server diversi se l'app diventa più popolare del previsto.

Si noti che 2 spazi di processo non devono significare 2 server. Possono entrambi condividere lo stesso hardware, ma dovrebbero avere il minor numero possibile di accoppiamenti tra loro, il che significa nessun accoppiamento nel codice.

Lungo l'idea di accoppiamento, abbiamo questo da Eric Evans

Code reuse between BOUNDED CONTEXTS is a hazard to be avoided.

Tutte le opzioni sopra riportate violano questa guida.

Quindi la tua domanda ha a che fare con la frase finale della definizione Microsoft di un Contesto Limitato. Queste sono le tue opzioni in ordine di preferenza

Ogni contesto può memorizzare nella cache le informazioni nei bisogni dagli altri contesti. Questo viene fatto tramite una coda di eventi o una coda di messaggi che tutti i contesti condividono, e come importanti cambiamenti di aggregazione essi informano altri contesti interessati. Julie Lerman ha una buona discussione su questo qui . Se si desidera utilizzare un singolo componente hardware, la coda messaggi può essere eseguita anche su quell'hardware, sebbene ciò introduca alcuni problemi di scalabilità e durata.

La seconda opzione è aggiungere un'API. So che dici di non averne uno, ma le API possono essere implementate come parte del contesto in modo che siano un piccolo lavoro extra. Possono anche essere bloccati per accettare solo richieste da localhost usando le regole CORS.

Terza opzione è un database condiviso, ma ora stiamo accoppiando i contesti in modo che questa sia una strada pericolosa. Se DEVI farlo, almeno costruisci le tabelle in schemi separati in modo che lo sviluppatore si accorga che stanno rompendo il muro tra i contesti.

Eviterei tutte e tre le opzioni che hai elencato. Non è difficile immaginare che i requisiti cambino in un contesto in conflitto con le regole in un altro. Dopotutto, è per questo che li hai separati in contesti separati per cominciare.

Se il Cliente è un'origine dati per Persona, allora ha il fine di disporre di un referente PersonRepository e di unRepository clienti.

Questo non infrange il contesto limitato perché PersonRepository è un servizio piuttosto che un oggetto Entity / Domain.

PersonRepository dovrebbe contenere le regole di trasformazione piuttosto che Person