Sourcing di eventi e aggregati cross-context

I had this idea of different write models being used in different bounded contexts, but both being the same aggregate instance (the same events).

Questo mi sembra una cattiva idea; molto in contraddizione con le migliori pratiche.

L'aggregato ha davvero bisogno di avere una fonte di verità. In un'implementazione di un evento, questa è davvero la storia dell'aggregato. La coerenza di quella storia è sorvegliata dall'aggregato stesso. Se si hanno due diverse implementazioni dell'aggregato (due diverse raccolte di regole aziendali - che consentono stati diversi), allora ti stai aprendo a un vero casino quando un'implementazione lascia la storia in uno stato che l'altro dovrebbe impedire.

Due diverse applicazioni potrebbero (potenzialmente) condividere lo stesso modello di dominio. Nel tuo caso, ciò potrebbe significare che uno dei contesti consente il comando quando l'altro lo proibisce.

Tuttavia, nel libro blu originale, un contesto limitato è un limite oltre il quale un modello non può essere applicato, dove cambia la lingua ubiquitaria e così via. Se le parole usate per descrivere il business non significano più la stessa cosa, allora condividere gli stessi aggregati sembra poco saggio.

Vedi anche: Con tutti questi servizi, come posso non essere anemico?

Si noti che non c'è assolutamente nulla di sbagliato con due diverse proiezioni che leggono il loro stato dalla stessa storia. Il contesto Utente può avere una vista della cronologia, in cui il contesto Amministrazione ha una visione completamente diversa della stessa storia.

I had this idea of different write models being used in different bounded contexts, but both being the same aggregate instance (the same events).

L'idea alla base di Bounded Contexts (BC) è di avere uno scopo ben definito che consente agli sviluppatori di risolvere un problema ben definito senza compromessi.

L'uso dello stesso aggregato in due BC non ha senso, per definizione: diversi BC hanno scopi diversi, e lo stesso modello che serve a scopi diversi porterà a una complessità accidentale, molto rapidamente.

Puoi avere BC con dati molto simili o sovrapposti , ma questa è un'altra storia (e un'analisi più approfondita dei dati mostrerà dettagli interessanti). Gli aggregati si formano attorno al comportamento, non ai dati.

Oltre ai problemi menzionati da altre risposte, sembra che tu stia confondendo le preoccupazioni.

Il fatto che un utente abbia effettuato l'accesso è un problema a livello di applicazione, non di dominio. Non dovrebbe essere usato per forzare l'invarianza all'interno di un aggregato.

L'accesso e il controllo dei permessi è una preoccupazione trasversale che nella maggior parte dei sistemi DDD non viene eseguita nel dominio ma fornita da un modulo di infrastruttura separato più lontano dal bordo del sistema.