DDD-Lite è un linguaggio di pattern per l'iniezione di dipendenza?

17

Mi sono imbattuto nel discorso di Greg Young 7 Ragioni per cui i progetti DDD falliscono quando menziona qualcosa che chiama DDD-Lite alle 7:20.

Riassumendo, in sostanza dice che alcuni usano DDD come linguaggi di pattern (entità, repository, oggetti valore, servizi, ecc.) Senza fare nient'altro correlato a DDD. Postula il 60% o più dei modelli di dominio in .Net sono DDD-Lite. Pensa che DDD-Lite stia fondamentalmente costruendo un linguaggio attorno all'iniezione di dipendenze, qualcosa che non devi davvero fare. Dice che fai interamente DDD o fai qualcosa di più semplice. Altrimenti sostiene che una persona sta mettendo tutto questo lavoro nella costruzione di buone astrazioni, ma senza alcun reale beneficio.

Devo ammettere che non so quanto di DDD vorrei e non ho ancora provato a usarlo. Non ho nemmeno letto il libro di Eric Evan. Sono molto più interessato a Dependency Injection e molti, molti libri e blog su questo argomento usano termini e concetti di riferimento tratti dal libro DDD di Eric Evans. Qui è dove sono stato esposto ai concetti di DDD. I libri che ho letto che fanno questo includono:

Iniezione delle dipendenze in .NET
Microsoft .Net: Architecting Applications for the Enterprise
Sviluppo di applicazioni Brownfield in .NET

Se si vuole fare l'iniezione di dipendenza, quali sono le alternative più semplici rispetto a fare "DDD-Lite?" Mi sembra che costruire buone astrazioni sia abbastanza utile indipendentemente dal fatto che si stiano usando i concetti di DDD in modo "DDD-Lite". (vedi i post sul blog di Mark Seemann: le interfacce non sono astrazioni e verso una migliore astrazione ). Faccio fatica a credere che chiunque stia facendo Dependency Injection stia anche facendo (o deve fare) un DDD completo. In qualche modo ho frainteso l'argomento di Greg Young su DDD-Lite?

— opaco
fonte

15

Iniezione di dipendenza e DDD sono due concetti disgiunti. Fare l'iniezione di dipendenza non richiede di fare DDD né DDD richiede l'iniezione di dipendenza.

Molti progetti DDD falliscono perché scelgono gli schemi ma trascurano il processo dietro DDD. Non impiegano il tempo necessario per estrarre le regole aziendali. Non si concentrano sul modello di dominio e su attente astrazioni. Non stabiliscono una lingua ubiquitaria.

In breve: immagino sia un malinteso

— saintedlama
fonte

4

+1 Gli schemi descritti nel libro di Evans sono ancora preziosi in un contesto molto più ampio - fintanto che si capisce che applicarli isolatamente non lo rende DDD.

— Mark Seemann,

1

Sì, realizzo DI! = DDD. @MarkSeemann, quindi l'argomento di Greg sembra essere che la gente stia dicendo che stanno facendo DDD quando non lo sono. Va bene lo capisco. Sostiene inoltre che l'utilizzo di astrazioni come quelle presenti nel DDD (aggregati, repository, entità di dominio, oggetti valore, servizi, ecc.) Non è necessario se vengono utilizzati solo per supportare un'architettura iniettata di dipendenza. Questa è la parte che non capisco (cosa c'è che non va). Forse tale è l' argomentazione di paglia , poiché l'uso di tali cose non è solo per "costruire un linguaggio attorno all'iniezione di dipendenza".

— Matt,

3

Greg è parzialmente corretto: gli schemi speciali in DDD non sono particolarmente correlati a DI. Tuttavia, nel mio libro ho raccolto un po 'della terminologia, in particolare la definizione di Entità vs. Valore Oggetto vs. Servizio perché è importante capire cosa iniettare dove. Tuttavia, sia questa terminologia che altri modelli come Repository e Factory sono molto più antichi del libro DDD, quindi dire che tali cose non sono necessarie al di fuori di DDD mi sembra errato. Può dipendere da come definisci effettivamente DDD.

— Mark Seemann,

2

Scommetto che Greg si riferisce alla semplice applicazione se un sottoinsieme di modelli di progettazione guidata dal dominio invece dell'intero approccio DDD. Il termine DDD-Lite si riferisce implicitamente al libro http://www.infoq.com/minibooks/domain-driven-design-quickly che un tempo era popolare tra i neofiti di DDD, ma un sacco di foto mancanti si concentra solo sul modelli di progettazione modellistica locale.

Sebbene l'iniezione di dipendenza sia considerata una buona cosa, non esiste una forte correlazione tra DDD e DI.

— ZioBrando
fonte