Ho alcuni oggetti che rappresentano un'applicazione web. Attualmente ho un oggetto cluster per rappresentare una distribuzione specifica dell'app. All'interno di un oggetto cluster ho i seguenti oggetti: Server, Cliente, Utente. Nessuno di questi oggetti può esistere senza essere parte di un cluster, quindi ho creato un repository cluster per recuperare i cluster dal database. Ora, dal cluster ho bisogno di ottenere una lista di clienti, presumibilmente usando un metodo nell'oggetto Cluster come GetCustomers(). Ora, il mio primo pensiero era di scaricare il lavoro di questa operazione su un CustomerRepository, ma poiché i repository sono solo per le radici aggregate, dove dovrebbe andare la logica di accesso ai dati? Questo appartiene a una classe di servizio?Se i repository sono per root aggregati, dove dovrebbe andare la logica di accesso ai dati per altre entità?
risposta
In sostanza, una radice Aggregazione è qualsiasi oggetto che potrebbe essere necessario recuperare come radice di un grafico oggetto. Solo perché un'entità specifica è una radice aggregata e ha un repository, non significa che un'altra entità che è una delle sue proprietà non possa essere anche una radice aggregata - con il proprio repository.
Un buon esempio è un sistema di fatturazione clienti. Il cliente sarebbe certamente una radice aggregata e conterrebbe una raccolta di fatture ... Ma per un'altra funzione di applicazione, la fattura stessa potrebbe essere una radice aggregata con gli oggetti LineItem costituenti nel suo oggetto grafico.
Quindi, nel tuo esempio, non c'è niente di sbagliato nella creazione di un altro repository per i clienti, se è necessario recuperarli indipendentemente dai cluster in alcune situazioni.
NOTA: vedere il thread nei commenti. Sebbene le entità root possano, (e spesso lo faranno) avere riferimenti ad altre entità root, è disapprovato (e potrebbe essere troppo mite un giro di frase) per consentire al repository di qualsiasi entità root di contenere la funzionalità che gestisce (crea, aggiorna , o cancella) qualsiasi entità radice nel suo oggetto grafico a cui ha un riferimento. Qualsiasi entità radice referenziata dovrebbe avere i propri repository individuali e la funzionalità per gestirli (operazioni di creazione, aggiornamento e/o cancellazione) dovrebbe essere nel proprio repository, in modo tale che sia solo in un punto.
- 1. Dove dovrebbe andare la logica di calcolo in un'app Rails?
- 2. Come devono essere applicate le regole per i Root aggregati?
- 3. DDD: Root aggregati
- 4. Accesso ai membri aggregati in sottoclasse
- 5. CodeIgniter: dove dovrebbe andare una particolare funzionalità?
- 6. CakePHP - dove mettere la logica di servizio
- 7. accesso ai dati in DDD?
- 8. modelli django = business logic + accesso ai dati? O il livello di accesso ai dati dovrebbe essere separato dal modello django?
- 9. Dove dovrebbe andare il codice per costruire i modelli di visualizzazione?
- 10. Repository generico con livello di accesso ai dati
- 11. Dove dovrebbe andare la rookie per le migliori risorse di tutorial SQL?
- 12. Dove dovrebbe andare la logica di autenticazione manuale in spring security - Livello di servizio o livello di presentazione?
- 13. Dove dovrebbe andare la proprietà CSS stile elenco?
- 14. Vue.js - accesso ai dati dall'istanza root all'interno del componente
- 15. Dove creare nuove entità di dominio? Controller, repository o mapper?
- 16. Sono necessari consigli per un grande livello di accesso ai dati .net
- 17. La logica di visualizzazione dovrebbe andare in un UIView o (quando applicabile) il suo UIViewController?
- 18. Accesso ai dati già scaricati
- 19. Altre alternative ai cookie
- 20. Motivo di progettazione per il livello di accesso ai dati
- 21. Dove criptare/decodificare i miei dati?
- 22. Modelli di progettazione per il livello di accesso ai dati
- 23. Accesso ai dati recuperati
- 24. Rifacturazione della logica di dominio che accede ai repository in un sistema legacy
- 25. Dove dovrebbe andare un file .xml di preferenze?
- 26. Schema del repository e logica aziendale
- 27. Dove dovrebbe essere posizionata la logica aziendale quando si utilizza Doctrine 2 e Zend Framework
- 28. Accesso SBT ai repository Maven locali
- 29. Dove sono i javadoc per Lotus 'Notes.jar?
- 30. Dove sono tutti i barattoli di javax?
Una radice aggregata è un oggetto responsabile del ciclo di vita di tutte le entità contenute. Esistono radici aggregate per mantenere invarianti di relazioni valide, l'accesso al recupero è una conseguenza di ciò, non la ragione per la creazione di una radice aggregata. Questa risposta sembra quasi suggerire una radice aggregata che dipende dalla prospettiva del chiamante. La fattura è una radice aggregata o non lo è. Periodo. Alla domanda iniziale se il Cliente viene considerato come radice aggregata, Cluster può ancora avere un riferimento ma il Cliente non fa più parte della radice aggregata del Cluster. – Sisyphus
Se comprendo correttamente la tua obiezione, è equivoco richiedere che non vi sia alcuna sovrapposizione all'interno dell'insieme di aggregati definiti, il che sarebbe inusuale e non necessario. Per il tuo altro punto su come basare gli aggregati sui requisiti di accesso del dominio dell'applicazione, cito da Evans, "... Fornisci repository solo per le radici di AGGREGATE che in realtà richiedono l'accesso diretto." Ovviamente, spesso accade che le entità che sono parte di un aggregato può essere necessario accedere direttamente, con i loro componenti, in un'altra parte dell'applicazione. –
Evans p124 "Un aggregato è un cluster di oggetti associati che trattiamo come un'unità ai fini delle modifiche dei dati." La radice è l'oggetto responsabile del controllo della modifica/accesso a tutti gli altri nell'aggregato. Ciò a cui mi oppongo è un'entità che a volte è una parte non radice di un aggregato e altre volte la radice del proprio aggregato. L'entità potrebbe essere cancellata come membro del primo aggregato, dopo di che non potrebbe avere il controllo del proprio aggregato. Una radice non può far parte di un altro aggregato perché è responsabile del mantenimento del proprio aggregato in uno stato valido. – Sisyphus