Quali dovrebbero essere le linee guida primarie nella definizione di un contesto limitato?

"Il contesto limitato dovrebbe essere relativamente piccolo, ma abbastanza grande solo per catturare la lingua ubiquitaria completa del dominio aziendale isolato, e non più grande"

Secondo me, la funzione primaria di un contesto limitato è di incapsulare un linguaggio comune utilizzato da un gruppo di utenti. Questo è lo strumento principale che consente di riflettere la terminologia già utilizzata nelle astrazioni software invece di creare astrazioni innaturali per soddisfare tutti gli utenti.

Le linee guida IMO primarie per disegnare i contorni del contesto non dovrebbero pensarci troppo . Si tratta di una terminologia già utilizzata, quindi devi lavorare con gli utenti, ascoltare la loro lingua, chiedere loro un significato e tracciare un confine quando è necessario (o semplicemente naturale).

Per quanto riguarda le linee guida specifiche, posso pensare a quanto segue:

1. Due entità dovrebbero essere separate da un limite di contesto se hanno lo stesso nome ma un significato diverso,
2. Un insieme di termini (chiamiamolo A) conosciuto da un gruppo di utenti dovrebbe probabilmente essere separato dal suo anti-set (intero dominio meno A).
3. Mantenere i contesti limitati autosufficienti (in grado di fornire funzionalità da soli) consente di spostarli in diversi processi, (micro) servizi o persino sistemi separati.

Una volta creato il dominio, puoi confrontarlo con i reparti dell'azienda (o qualsiasi altra cosa) come parte di un'analisi post-mortem.

Un contesto limitato contiene un modello di dominio. In genere, un contesto limitato rappresenta un'applicazione o un micro / servizio.

Una grande applicazione come una suite ERP, potrebbe avere più contesti limitati che rappresentano le diverse applicazioni nella suite, ad es. CRM, Contabilità, Acquisti, Risorse umane.

Se si modifica parte di un'applicazione esistente, può essere comune riconoscere la parte esistente, immutabile come un contesto limitato e la nuova parte come contesto limitato.

La sovrapposizione tra contesti limitati, ovvero la condivisione di parti del modello, è raramente intrapresa con successo, e in questi giorni è in disaccordo con le più moderne architetture di servizio / microservizi.