Il riferimento per ID tra Aggregati porta a un modello di dominio anemico?

La raccomandazione di Vaughn Vernon è una delle migliori regole tattiche da seguire. Se hai davvero bisogno di contenere un riferimento a un'altra radice aggregata, devi rivedere il limite del tuo aggregato come molto probabilmente sono sbagliati.

In questo caso il modello è anemico perché il business è anemico , non ha invarianti che è necessario proteggere, almeno da quello che hai presentato. In ogni caso, aggregates dovrebbe essere usato sul lato scrittura / comando della tua architettura; Lo sto specificando perché, in quasi tutti i domini, "search" è un'operazione di lettura / query, ma suppongo che il tuo dominio sia speciale in cui una "ricerca" implica una mutazione di stato.

Non penso che tu abbia in realtà due radici aggregate qui. Una radice aggregata è un'entità - che significa che ha "continuità e identità" a livello di dominio. Dalla tua descrizione, dai commenti e dagli esempi di codice, sembra che solo il tipo Search sia in realtà un'entità. BatchSearch sembra mancare di tale identità (almeno, nessun ID simile appare nella prima versione del codice), il che probabilmente lo rende un servizio (DDD), specialmente se non ha uno stato visibile esternamente. Potrebbe anche essere trattato come un oggetto valore, a seconda di come lo si utilizza. Ora, se si tratta di un servizio, si noti che questo non significa che si dovrebbe spostare la funzionalità in qualche metodo di utilità; i servizi possono essere implementati come oggetti (ed essere polimorfici, avere dipendenze, ecc.).

I punti di Vaughn Vernon riguardano il caricamento e la modifica dello stato degli aggregati. Un aggregato è un gruppo di entità correlate e oggetti valore che ha un'entità esternamente visibile (la radice aggregata - essenzialmente un Facciata ), che ha due scopi: (1) definisce le regole di attraversamento e nasconde la complessità e (2) fornisce alcune garanzie sulla consistenza dell'aggregato nel suo complesso quando subisce delle modifiche. Nell'articolo a cui ci si è collegati, il problema ruota attorno all'idea che due aggregati associati non debbano essere modificati in una singola operazione atomica, poiché questo ha implicazioni di progettazione e prestazioni (supponendo che la coerenza atomica sia l'obiettivo).

Quindi per evitare questa situazione, raccomanda di fare riferimento all'altra aggregazione (che, ancora una volta, è un'entità) dal suo ID di dominio. Ciò non impedisce completamente lo scenario problematico, ma lo rende più difficile da realizzare, consentendo comunque la navigazione verso l'altro aggregato. C'è anche l'ulteriore vantaggio di un ridotto ingombro della memoria, nel senso che i due aggregati vengono caricati indipendentemente.

Nella sezione Navigazione del modello parla di come è possibile utilizzare una forma di caricamento lento per supportare la navigazione tra le radici aggregate e procede a raccomandare "utilizzare un repository o un servizio di dominio per cercare oggetti dipendenti prima di invocare il comportamento aggregato ", anziché cercare le dipendenze tramite un repository dall'interno di un aggregato, che è in realtà solo un'applicazione del principio di inversione delle dipendenze (dove questo" repository o servizio di dominio "viene utilizzato per eseguire manualmente l'iniezione delle dipendenze).

Inoltre afferma che se questo approccio semplicemente non funziona, allora dovresti considerare di progettare il tuo sistema per un'eventuale coerenza (cioè, il sistema non dovrebbe presumere che un aggiornamento riuscito di un aggregato significhi che un anche il relativo aggregato è stato modificato di conseguenza, ed è in uno stato valido in quel momento), e quindi descrive un approccio basato sugli eventi per costruire un tale sistema.

Ora, la domanda è: qualcuna di queste cose si applica alla tua classe BatchSearch ? Ha un'identità non transitoria a livello di dominio? È meglio modellato come un servizio che costruisce e restituisce un gruppo di entità di dominio (% istanze diSearch)? Inoltre, lo stesso articolo sottolinea che ci sono casi in cui si può decidere di infrangere le regole, e elenca diversi motivi per farlo, che è anche qualcosa da considerare.

Un modo per unificare il modello sarebbe utilizzare Cerca come radice aggregata con il modello Invocazione come parte dell'aggregato.

Non è diverso da come hai già modellato, ma pensando a Ricerca e BatchSearch come due diversi modelli di aggregazione devono andare via.

Memorizza Cerca come risorsa con flag che rappresentano lo stato in batch o meno.

class Search {
    List<Invocation> invocationList;
    boolean: batched; 

    // you can check size of the list to determine whether it's batched or not - this simplifies the model further
}

class Invocation {
    List<SearchParameters> searchParameterList;

    ..
    //add more fields as required
    .. 
}

Progetta i tuoi casi d'uso e modellali intorno a trattare ciascuna chiamata come Cerca con un numero diverso di invocazioni (a seconda dei casi d'uso che potresti chiamare "Invocazione" in modo diverso).

Quindi i modelli resterebbero all'interno del limite della radice aggregata nel contesto specificato.

Spero che aiuti. Fammi sapere se devo tenere conto di eventuali problemi di progettazione mancanti.