Contenitori IoC e Domain Driven Design

Question

Ho cercato indicazioni per l'utilizzo di contenitori IoC nella progettazione basata sul dominio. Il libro di Evan sfortunatamente non tocca l'argomento. Le uniche linee guida sostanziali che ho trovato su internet sono here.

Molti dei punti di Malovic sono di buon senso ma sono preoccupato per alcuni di loro. Suggerisce che i contenitori IoC dovrebbero essere riservati solo per la risoluzione dei servizi e che l'utilizzo di un contenitore IoC per risolvere le dipendenze dei domini è una cattiva idea. Tuttavia, non sostiene questa affermazione con alcun esempio. Semplicemente lo afferma come un dato di fatto.

Quindi prosegue dicendo che la combinazione di contenitori e fabbriche IoC non ha senso. Questo sembra contraddire il suo primo punto. Se, infatti, le dipendenze del dominio non dovessero essere risolte da un contenitore IoC, come dovrebbero essere risolte? Il libro di Evan indica chiaramente le fabbriche come la scelta logica.

Apprezzerei qualsiasi input che avete in merito. Sono un principiante quando si tratta di DDD e IoC. Sto lottando per capire come IoC e DDD possano lavorare insieme.

Answer 1

A mio parere, ha ragione a non utilizzare il contenitore IoC nel modello di dominio. Quella pratica mi seguo anche io. L'idea di base è che i servizi possono contenere dipendenze da infrastrutture e quindi è saggio prenderli in giro. Le entità di dominio non ne hanno, quindi non è importante prenderle in giro (la codifica continua verso le interfacce è una buona pratica).

Le fabbriche per le entità di dominio non devono essere nel contenitore IoC, ma le fabbriche per i servizi dovrebbero. Fondamentalmente puoi fare riferimento a fabbriche di entità nei tuoi servizi. Non è un accoppiamento molto stretto.

Buona lettura merito IOC possono essere trovate all'indirizzo Billy McCafferty's blog post "Dependency Injection 101"

Answer 2

IOC

contenitori sono prezioso nella progettazione codice dell'unità controllabile e sono ortogonali a DDD. Potresti creare la tua implementazione di modelli di fabbrica e costruttore se vuoi ... dal perché passare attraverso il problema?

Assolutamente. Utilizzare un contenitore IOC che sia abbastanza potente per soddisfare i requisiti specifici dell'utente; Ne più ne meno.

Answer 3

Utilizziamo DDD e l'iniezione di dipendenza (il modello), ma non utilizzare un framework di iniezione delle dipendenze.

Un problema con i framework di distribuzione delle dipendenze è il modo in cui separano la configurazione in file XML. XML è un ottimo linguaggio di marcatura. Come è diventato un linguaggio di configurazione, non capirò mai. Il problema, ovviamente, è che devi eseguire l'applicazione prima di sapere se tutto è cablato correttamente. È anche difficile vedere quale codice viene utilizzato dove. Se si utilizzano interfacce, l'unico riferimento a un'implementazione sarà in un file XML, che è più difficile da individuare. E alla fine perdi sicurezza di tipo e generici. (Una volta ho visto un orribile bug nella produzione che sarebbe stato catturato dal compilatore se non avessimo usato XML.)

Vorrei sottolineare che non sto dicendo che l'iniezione di dipendenza sia negativa. È un modello fondamentale di buona progettazione di oggetti. Ma non c'è assolutamente niente di sbagliato nel fare il cablaggio in una fabbrica.

Nei miei ultimi due progetti abbiamo rimosso grandi quantità di "codice" dai file XML e nelle fabbriche. Le fabbriche sono cablate con servizi gestiti dal contenitore (come connessioni JDBC, connessioni JMS e così via). L'applicazione è diventata molto più semplice da capire, perché la fabbrica è meno prolissa di XML. E come programmatore Java, è molto più semplice collegare un programma usando lo spazio di controllo, anziché il gioco d'azzardo XML - e il tuo IDE evidenzierà quando hai rotto qualcosa.

In un test di integrazione, basta creare gli oggetti come si farebbe in una fabbrica.

cioè,

dbConnection = DatabaseConnectionFactory.connection();  
serviceUnderTest = new PaymentProcessor(new CustomerRepository(connection));