2013-04-16 12 views
6

Sto lavorando a un progetto utilizzando sia la progettazione basata su domini sia lo sviluppo basato su test. Durante la lettura del libro DDD di Evans, ho notato che non definiva le interfacce per le radici aggregate nel dominio.Se una radice aggregata implementa un'interfaccia nella progettazione basata sul dominio

Se eseguo sia DDD che TDD, dovrei definire le interfacce per ogni radice aggregata per rendere le classi di radice aggregate facilmente controllabili e verificabili? In tal caso, dovrei definire anche le interfacce per ogni entità contenuta all'interno della radice aggregata?

Dalle mie ricerche su Google e StackOverflow, ho trovato risposte che si avvicinano a ciò che sto cercando, ma sono specificamente alla ricerca di consigli quando si eseguono DDD e TDD perché la mia ipotesi è quella della testabilità, quando facendo TDD, potrebbe essere trascurato nelle risposte che ho visto finora.

+0

questa è una domanda ampia. potresti voler dare un esempio di ciò che il tuo edificio ha per ottenere risposte più specifiche. così com'è si potrebbe ottenere molto la risposta 'dipende' –

+1

Hubson, mi scuso per l'ampiezza della domanda. Per chiarire, sto specificatamente cercando di determinare se Evans intenzionalmente non ha definito le interfacce per le radici aggregate nei suoi esempi nel libro per mantenere gli esempi semplici (cioè per ignorare aspetti, come TDD, al di fuori dell'argomento del libro) o se li ha esclusi perché non forniscono alcun valore aggiuntivo nemmeno quando fanno TDD. L'esempio in questione sarebbe l'applicazione cargo Evans usata come esempio nel libro Domain-Driven Design. Spero che questo aiuti a restringere la portata della domanda. Grazie per il feedback. –

+0

non ci sono scuse necessarie e questo è concreto. passando solo quello che ho imparato. la gente ama questo tipo di domanda in coppia con "ecco dove sono" i diagrammi di codice/architettura. –

risposta

4

No, prova direttamente contro l'aggregato. L'aggregato stesso non dovrebbe avere dipendenze iniettate e se un comportamento specifico richiede una dipendenza, di solito dovrebbe essere espresso come un'interfaccia. Un'interfaccia su un aggregato è un'astrazione inutile - c'è solo un'implementazione di comportamenti - questo è il punto. Inoltre, dai uno sguardo allo BDD and DDD - Lo sviluppo basato sul comportamento può essere visto come un'evoluzione del TDD e si allinea bene con il DDD.

+0

possiamo parlare di cosa intendi per astrazione inutile? http://chat.stackoverflow.com/rooms/28305/domain-driven-design –

+0

gli darò un colpo, potrebbe essere difficile da ottenere allo stesso tempo .. – eulerfx

+1

Ho fatto un po 'più di ricerca dal Ho postato questa domanda due giorni fa e quello che ho imparato è che la questione della creazione di interfacce per tutte le entità di dominio (incluse le radici aggregate) è un argomento ampio e molto dibattuto (anche senza considerare TDD o DDD). Detto questo, presumo che non ci sarà una risposta chiara. Quindi devo supporre che Evans abbia intenzionalmente escluso le interfacce per le radici aggregate a causa delle ragioni che hai affermato. Quindi, ho intenzione di andare avanti con questo approccio e vedere come va. Grazie per il tuo feedback! –

3

Sono solito definire interfaces for all entities and domain services per semplificare il test dei client che utilizzano il dominio. Inoltre tale approccio facilità AOP quando richiesto.

Per quanto riguarda gli oggetti valore, dipende. Ad esempio, non utilizzo le interfacce per gli argomenti dell'evento, identifiers, exceptions (ovviamente) e qualche altro tipo di "contratto". Tuttavia, ho dovuto introdurre un'interfaccia per facilitare l'isolamento del test del codice client. Quindi la mia regola generale è: quanti passi il cliente richiede per ottenere l'oggetto valore nello stato desiderato? Se è più di uno (o due, il buon senso è mio amico MrGreen), introduco un'interfaccia sin dall'inizio.

Nota Non sto parlando di aggregati, poiché tutti i miei aggregati sono anche entità.

Problemi correlati