DDD: cosa succede se l'aggregato dipende da altri aggregati

I am modelling UserAggregate using DDD concepts. I know that two separate users should be independent, but when creating a new user, I need to validate, that there is no other user with the same username. How do I approach such a situation?

Il termine di ricerca per questo tipo di problema è set validation .

Alcune risposte comuni

1) Indaghi e scopri che la "regola" in realtà non è tanto importante per il business, e quindi fai il massimo sforzo per evitare collisioni e rapporti di incidenti / eccezioni che rilevano possibili conflitti per la risoluzione umana . "Se quel nome non era in uso un secondo fa, abbastanza buono - ci occuperemo delle corse di dati a mano."

2) Punt e l'onere di mantenere la regola aziendale sull'appliance di archiviazione. Vale a dire, si archiviano tutti gli utenti in un database relazionale e si applica il vincolo di unicità lì. Questo non si adatta a tutte le opzioni di archiviazione: lo storage NoSQL probabilmente avrà un problema qui.

3) Aggiornate il vostro modello, in modo che il set che deve essere valido sia un aggregato a se stesso. Per un caso come questo, il "set" sarebbe probabilmente qualcosa di simile a una mappa di nomi utente sugli identificatori dell'utente.

4) Aggiorna il tuo processo, in modo che tutte le richieste per un determinato nome utente vengano instradate allo stesso stesso utente - analogamente all'utilizzo del nome utente come identificativo dell'utente.

5) Riconosci che la gestione degli utenti non è una preoccupazione unica per la tua azienda, e trovi una soluzione off the shelf e ad adatta i tuoi processi ad essa. Se gli utenti non sono il tuo core business, questa è spesso la strada giusta da percorrere.

Suppongo che UserAggregate debba modellare un User ? In tal caso, la creazione dell'utente dovrebbe probabilmente non esserci. Chiunque "crea" effettivamente gli utenti potrebbe verificare se il nome utente è unico e, sì, dovrebbe avere tutte le dipendenze necessarie per farlo.

Se UserAggregate non è un User di quanto sia probabilmente una classe tecnica, nel qual caso il design è già un po 'off.

Due pensieri di follow-up:

1. Scegli nomi di classi significativi. Significativo significa che una persona d'affari (familiarità con l'argomento) avrebbe capito di cosa si tratta. UserAggregate è tecnico quindi non un buon nome.

2. La maggior parte dei database (relazionali o di altro tipo) catturerebbe una chiave non univoca, non esitare a delegare se puoi.

In un caso come questo puoi considerare che questa regola di convalida non si adatta alla tua logica di dominio. In tal caso, questa logica di convalida dovrebbe verificarsi nel livello del servizio dell'applicazione, durante la convalida del comando di input:

• viene ricevuto un comando CreateUser con lo username come payload
• il gestore di comandi nel servizio dell'applicazione verifica che il file il nome utente è unico utilizzando il tuo UserRepository
• il comando è accettato o rifiutato in base a questa regola

Se ritieni che questo processo di validazione appartenga alla tua logica di dominio, puoi utilizzare un DomainService invece del servizio Applicazione per gestire questa logica. I passaggi sono gli stessi, ma la verifica è gestita da un qualche tipo di servizio di dominio UserValidationService (nominalo meglio di me, con un linguaggio che riflette la tua lingua ubiquitaria in quel caso).