DDD Corretta divisione degli aggregati e eliminazione di troppi riferimenti

2

Sto progettando un'applicazione, che aiuterà la progettazione di impianti elettrici. Sono andato per Domain Driven Design, in quanto l'argomento è complesso e l'applicazione crescerà con le conoscenze acquisite. Tuttavia, sono principiante di questo concetto. Per ora, ho un problema per modellare correttamente il dominio, specialmente per dividere le entità in aggregati.

Ho definito il cablaggio - Installazione come un insieme di ConnectionPoints e Cavi , che li connettono. Uno ConnectionPoint ha uno o più cavi . Ogni cavo ha una serie di cavi. Considero la fine di un filo come un Terminale , che possiamo collegare a un altro Terminale che crea una Junction . I Terminali si differenziano l'uno dall'altro, poiché i fili hanno colori e scopi diversi. Giunzioni sono costituiti da due o più Terminali e possono essere eseguiti solo all'interno di ConnectionPoint . L'ho illustrato per una migliore comprensione:

Oltre ai Cavi ci sono anche Dispositivi , che hanno anche Terminali . Sono anche collegati in un ConnectionPoint e i loro Terminali sono trattati allo stesso modo dei Cable di Terminali . Per ciascun dispositivo devo essere in grado di monitorare, a cui è collegato il terminale (potrebbe trattarsi di un elenco di endpoint).

Il problema, con il design, è la necessità di avere riferimenti a Terminali al di fuori di un cavo e entità per creare Giunzioni e traccia le connessioni. Potrei prendere in considerazione un Cavo e un Dispositivo come aggregati di Terminali , poiché Terminali non possono esistere senza di essi e come la conoscenza del genitore di Terminal è importante. Tuttavia, ogni Terminale ha anche un'identità esterna a un Cavo / Dispositivo e non ho idea di come più avanti nel codice e nel database potrei mantenere la conoscenza delle connessioni effettuate.

Hai qualche idea come potrei modellarla? Quali domande dovrei chiedermi per definire un modello corretto ed evitare di mantenere i riferimenti ovunque?

    
posta krzychu 18.11.2013 - 11:33
fonte

2 risposte

1

Il punto di DDD è di consentire il comportamento complesso espresso nel modello di dominio e non solo la struttura complessa. E quello che stai descrivendo è solo una struttura statica. Credo che DDD non ti possa aiutare qui. Se hai un comportamento del genere, il modo migliore è usare TDD e lentamente evolvere l'intero progetto. Se non lo fai, dovresti guardare indietro alle tecniche di modellazione standard e non usare DDD.

Gli aggregati sono grandi se si desidera mantenere invarianti specifici su più entità diverse correlate, ma possono essere problematici durante la modellazione di relazioni complesse, proprio come si sta vivendo.

    
risposta data 16.02.2014 - 17:06
fonte
0

Un aggregato è un'entità o un gruppo di entità che devono rimanere coerenti all'interno di una determinata transazione.
Per esempio. considerare un cavo elettrico con più fili: se si invia corrente attraverso di esso, la corrente viaggia nella stessa direzione su ciascuno dei fili. In un'app DDD, avresti un metodo sul cavo "TransferCurrent". Tale metodo risiederebbe sulla radice aggregata (cavo) e non sui fili, poiché la corrente non può viaggiare in direzioni diverse su fili dello stesso cavo, il che renderebbe il cavo incoerente.
Spero che l'esempio abbia un senso, il tuo dominio è piuttosto estraneo a me. Ma il succo è: cercare entità o gruppi di entità che devono rimanere coerenti all'interno di una determinata transazione.
Inoltre, tieni presente che le radici aggregate possono fare riferimento solo a id altre radici aggregate, non a entità che possono risiedere all'interno di un aggregato. Il contrario è comunque possibile.

    
risposta data 18.11.2013 - 11:45
fonte

Leggi altre domande sui tag