Confusione sul significato della parola aggregato nella progettazione guidata dal dominio

Per la terminologia in Domain Driven Design, inizia da "il libro blu" - Domain Driven Design di Eric Evans.

AGGREGATE A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the aggregate, designated as the root. A set of consistency rules applies within the aggregate's boundaries.

Quest'ultima frase, penso che tu possa girarti: i confini dell'aggregato sono definiti dalle regole di coerenza.

È sicuramente il caso che un aggregato abbia stato. Ogni volta che il modello di dominio cambia, un aggregato viene preso da uno stato coerente all'altro. I dati che persistono sono usati per ricostruire questo stato. Quindi in questo senso, è una cosa reale.

Ma l'aggregato stesso non ha necessariamente una parola nella lingua ubiquitaria. È un concetto derivato.

In generale, potremmo inserire l'intero modello di dominio sotto un singolo aggregato, che applica tutte le regole di coerenza. Non lo facciamo perché il design non è scalabile: non possiamo cambiare il modello di dominio in due modi diversi contemporaneamente, anche quando le modifiche che stiamo apportando non condividono alcuna regola di coerenza. È un modo scadente di modellare un'azienda che può fare più di una cosa alla volta.

Invece, scomponiamo le regole di coerenza in serie, soggetto al vincolo che due regole che fanno riferimento agli stessi dati devono far parte dello stesso insieme. (Nel fare questo, stiamo anche lavorando con il linguaggio onnipresente e gli esperti di dominio per determinare se stiamo descrivendo correttamente le regole di coerenza).

Per aggiornare il modello, identifichiamo l'aggregato responsabile di un dato e proponiamo il cambiamento. Se l'aggregato verifica tutte le sue regole di coerenza locale, sappiamo che la modifica è valida a livello globale e possiamo applicare la modifica. Ciò ripristina la nostra capacità di fare più di una cosa alla volta: le modifiche ai dati in aggregati diversi non possono in alcun modo essere in conflitto tra loro, per costruzione.

Le best practice suggeriscono che la maggior parte degli aggregati dovrebbe contenere solo l'entità radice. In questo modo puoi aggregare l'aggregato all'entità senza troppi rischi. Ma suppongo che di solito non ci sia nulla nella lingua onnipresente da appendere al cluster quando include più di una entità; così finisci con l'aggregazione ShoppingCart mantenendo le regole di coerenza per l'entità ShoppingCart e la collezione di entità CartItems e ....

Il caricamento parziale di un aggregato viene interrotto quando si tenta di applicare una modifica: in che modo un aggregato ben progettato può convalidare tutte le sue regole di coerenza con un sottoinsieme di dati? È certamente il caso che, se hai un requisito in cui ciò ha senso, la tua modellazione è rotta da qualche parte.

Ma se stai facendo una lettura, il caricamento di solo alcuni dei dati custoditi dall'aggregato può avere senso. Command Query Responsibility Separation (CQRS) fa un ulteriore passo avanti; una volta che il modello ha verificato che i dati soddisfano le regole di coerenza, è possibile riorganizzare completamente tali dati in qualsiasi formato di sola lettura che semplifichi la vita. In altre parole, se non si è interessati alle modifiche dei dati, non è necessario preoccuparsi del perimetro complessivo.

Non c'è "database" o "transazione" in DDD. DDD è completamente agnostico per database, transazioni o "consistenza finale". Quindi qualsiasi definizione che includa quelle non è valida per DDD.

Questo lascia fondamentalmente solo la tua definizione di pugno. Quale ritengo sia quella giusta.

Inoltre, non vedo come puoi sentire la descrizione di Martin Fowler che si adatta a qualsiasi altra cosa rispetto alla prima definizione.

Ma posso vedere come possa insinuarsi la confusione quando si pensa al "DDD pratico". Ciò significa che l'infrastruttura DDD + viene costruita su di essa. Ad esempio, potrebbe non avere senso materializzare l'intero aggregato dal database se si sta lavorando con una parte di esso. Ma poi, vorrei mettere in discussione se l'aggregato è davvero progettato correttamente. Forse dovrebbe essere diviso in più aggregati. In entrambi i casi, se si avvia l'infrastruttura di branding in esso, smette di essere un concetto di DDD e diventa concetto diverso. L'unica cosa che puoi fare è rendersene conto e assicurarti che tutti in squadra concordino cosa significhi "aggregare" e quali proprietà ha. Ricorda, i nomi sono fondamentali per una comunicazione efficiente. E la comunicazione con il tuo team ha priorità contro la comunicazione con il mondo esterno.

Mi sembra che Vaughn stia lottando con i problemi pratici delle radici aggregate monolitiche nel software in stile "linea di business".

Dove Martin ama il software OOP monolitico, che funziona bene quando si può adattare l'intero processo alla memoria.

Non penso che ci sia una contraddizione tra i due però. Devi scegliere dove dividere i tuoi oggetti di dominio in contesti e aggregati in DDD. Da una parte vuoi avere radici aggregate che comprendono un intero processo di vita reale, dall'altra hai difficoltà pratiche se queste diventano troppo grandi, quindi potresti doverle dividere un po 'più piccole e unirle a eventi di dominio o altro inganno