A parità di condizioni probabilmente preferiremmo utilizzare un singolo BC per tutto. Ma questo è semplicemente impossibile per una serie di motivi.
In primo luogo, c'è sempre un ecosistema che circonda ogni singolo sistema e spesso il sistema deve interagire con altri sistemi nell'ecosistema.
Questi altri sistemi sono ospitati da diverse organizzazioni (aziende, dipartimenti, agenzie) con responsabilità diverse, diverse motivazioni e obiettivi di business, e possibilmente diversi requisiti legali / normativi. Quelle organizzazioni diverse vorranno spesso ospitare i loro servizi a modo loro indipendentemente dagli altri membri dell'ecosistema.
In secondo luogo, suddividere un BC in più BC è un metodo per ridimensionare il sistema, sia in termini di carico di picco, ma anche in termini di facilitazione di parti indipendenti accoppiate liberamente per favorire lo sviluppo, l'evoluzione, la manutenzione e le operazioni più facili. (Ci sono vantaggi a lungo termine per avere più BC, ma ci sono anche costi in complessità.)
In questo caso particolare, la gestione dei passeggeri può memorizzare le informazioni sull'account del cliente, possibilmente incluso login / password, informazioni di pagamento (carta di credito), preferenze personali, tra gli altri. I progettisti del sistema possono ritenere che siano dati importanti da proteggere e sviluppare per favorire e mantenere buone relazioni con i clienti. Logicamente parlando, questo sistema cliente è probabilmente un sistema molto più grande di quello mostrato da questo flusso di servizi, quindi viene trattato come un BC indipendente.
isn't the sole purpose of bounded context to provide higher level of automicity[sic] and avoid BC leave its boundaries in order to serve this solution space?
Lo scopo principale del Contesto Limitato nel Design Driven Domain è fornire il contesto per la modellazione di un dominio. Ogni BC ospita un modello di dominio che inizia con concetti / termini ben definiti (vocabolario), le loro relazioni e i loro comportamenti. Ogni componente o servizio nel BC dovrebbe essere progettato per adattarsi correttamente al modello di dominio del BC.
Il BC è effettivamente un'unità di progettazione contestuale e concettuale, e per estensione quindi, anche una sorta di unità di implementazione (poiché l'implementazione segue i progetti del modello di dominio). Il fatto che il BC tenda a fornire sia l'autonomia che l'atomicità a seconda di quello che stavi cercando, è più un'estensione naturale del trattamento di ogni modello di dominio e del suo BC come unità da implementare, e che all'interno di quell'unità di implementazione ci aspettiamo il suo sotto -componenti per avere accoppiamenti più stretti di quelli che si verificano tra BC's.
