Domanda di progettazione DDD

Question

Domanda di progettazione DDD

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

4

Ho una domanda sulla modellazione di una radice Entity \ Aggregate in DDD. Sto refactoring un progetto che utilizza Entity Framework e business logic come servizi, i servizi contengono molta logica che credo dovrebbe essere nelle entità in DDD.

public class Contractor
{
   public int Id {get;set;}
   public DateTime ContractStartDate {get;set;}
   public DateTime ContractEnddate {get;set;}
   public string PhoneNumber {get;set;}
   public Address Address {get;set;}
   /*Bunch of other properties */
   public ICollection<Site> ContractorSites {get;set;}
}
public class Site
{
   public int Id {get;set;}
   /*Bunch of other properties */
}

Ora sto provando a modellare il contraente come entità. Il problema che sto affrontando è con la proprietà ContractorSites. Un appaltatore può avere uno o più siti a lui associati.

Ora, quando modifico un imprenditore come Entità, dovrei includere questa proprietà? Se includo questo significa che ogni volta che voglio recuperare i dettagli di un appaltatore dal database e creare questa entità (, dovrò anche recuperare i siti correlati?

La mia domanda si riduce a "dovremmo includere tutte le navi di relazione nell'entità del dominio?"

domain-driven-design design-patterns domain-model

posta Sri Harsha Velicheti 27.08.2015 - 03:04

fonte

3 risposte

Leggi altre domande sui tag domain-driven-design design-patterns domain-model

Devo utilizzare la mia API pubblica per la mia interfaccia web? Algoritmi di ordinamento sequenziale ottimali a dimensione fissa

score 1 · Answer 1

Un appaltatore può essere assegnato a diversi siti.

A un sito possono essere assegnati più appaltatori.

Quando recuperi i siti per un appaltatore, recupererai anche gli appaltatori associati a ciascun sito? E poi recupererai i loro siti?

Lasciando la valutazione pigra e la risoluzione di riferimento già implementata in EF, il lavoro per te paga davvero i dividendi in termini di tempo risparmiato. Implementare queste relazioni a mano nel tuo livello di dominio su Entity Framework è un lavoro molto utile a poco vantaggio.

Invece di sforzarmi per rispondere a questa domanda ora, vorrei tenere a bada e lasciare emergere un modello che mostri quale tipo di relazioni sono richieste frequentemente dalla tua app, o in alternativa, aspettare che emerga un problema (non indotto dal refactor) ciò richiede un ritocco al design esistente.

Vorrei anche considerare di restituire le entità EF al livello applicazione, a meno che tu non abbia una buona ragione per non farlo. Sebbene le tue entità diventino in qualche modo un problema trasversale, il lavoro richiesto per reimplementare e mappare gli oggetti tra i livelli dell'applicazione (specialmente se c'è poco o nessun riutilizzo da parte di altre applicazioni) potrebbe non valerne la pena.

score 1 · Answer 2

Secondo Vaughn Vernon è meglio usare il framework di entità come oggetti di stato quando si progettano gli aggregati quando si progettano gli aggregati perché sono rigidi rispetto ad altri ORM.

Con questo in mente. Perché stai iniziando con le entità? In DDD è necessaria una radice aggregata per mantenere il confine di consistenza. Una radice aggregata può avere entità e oggetti valore.

Per rispondere alla tua domanda. A meno che il sito non sia un oggetto valore, non è possibile condividere un sito tra più appaltatori. Se più appaltatori possono logicamente appartenere allo stesso sito, è necessario rendere Site una radice aggregata e quindi archiviare solo l'ID. Oppure visualizzalo come un oggetto valore immutabile e salva la stessa copia in più aggregati.

score 0 · Answer 3

In generale, hai bisogno di più concetti e più relazioni tra di loro, altrimenti avrai problemi con l'espansione della modellazione.

Per uno, mi sembra che manchi una nozione di Contratto. La nozione di data di inizio e data di fine si riferisce più al contratto specifico piuttosto che al contraente (il contratto si riferisce quindi al contraente). Penso che dovresti rendere Contractor, Contract, Contract Site tutti come entità separate - potrebbe esserci una sola radice aggregata per i principianti, ma sospetto che alla fine farai anche alcune di queste radici separate.

Inoltre, dovresti tenere conto delle molteplicità nelle informazioni di contatto, il che significa che probabilmente dovrebbero anche essere separate.