O DDD-Lite é uma linguagem padrão para injeção de dependência?

17

Eu me deparei com a palestra de Greg Young, 7 razões pelas quais os projetos DDD fracassam, onde ele menciona algo que chama DDD-Lite às 7:20.

Resumindo, ele basicamente diz que alguns usam o DDD como uma linguagem de padrões (entidades, repositórios, objetos de valor, serviços etc.) sem fazer mais nada relacionado ao DDD. Ele postula 60% ou mais dos modelos de domínio em .Net são DDD-Lite. Ele acha que o DDD-Lite está basicamente construindo uma linguagem em torno da injeção de dependência, algo que você realmente não precisa fazer. Ele diz que faz DDD inteiramente ou faz algo mais simples. Caso contrário, ele afirma que uma pessoa está realizando todo esse trabalho na construção de boas abstrações, mas sem benefícios reais.

Devo admitir que não sei tanto sobre DDD quanto gostaria e ainda não tentei usá-lo. Também não li o livro de Eric Evan. Estou muito mais interessado em Injeção de Dependência e muitos livros e blogs sobre esse assunto usam termos e conceitos de referência do livro DDD de Eric Evans. Foi aqui que fui exposto aos conceitos de DDD. Os livros que tenho lido que fazem isso incluem:

  • Injeção de Dependência no .NET
  • Microsoft .Net: arquitetando aplicativos para a empresa
  • Desenvolvimento de aplicativos Brownfield em .NET

Se alguém quiser fazer a injeção de dependência, quais são as alternativas mais simples do que fazer o "DDD-Lite?" Parece-me que construir boas abstrações é bastante útil, independentemente de alguém estar usando conceitos do DDD da maneira "DDD-Lite". (consulte as postagens do blog de Mark Seemann: interfaces não são abstrações e rumo a melhores abstrações ). É difícil acreditar que todo mundo que faz a injeção de dependência também esteja fazendo (ou precisa fazer) DDD de pleno direito. De alguma maneira eu não entendi o argumento de Greg Young sobre DDD-Lite?

.net dependency-injection domain-driven-design abstraction Matt
fonte

Respostas:

15

Injeção de Dependência e DDD são dois conceitos disjuntos. Fazer injeção de dependência não requer DDD nem DDD exige injeção de dependência.

Muitos projetos de DDD falham porque selecionam os padrões, mas negligenciam o processo por trás do DDD. Eles não levam tempo para extrair regras de negócios. Eles não se concentram no modelo de domínio e em abstrações cuidadosas. Eles não estabelecem uma linguagem onipresente.

Em suma: acho que isso é um mal-entendido

saintedlama
fonte
4
+1 Os padrões descritos no livro de Evans ainda são valiosos em um contexto muito mais amplo - desde que se entenda que aplicá-los isoladamente não o torna DDD.
Mark Seemann
1
Sim, eu percebo DI! = DDD. @ MarkSeemann, então o argumento de Greg parece ser que as pessoas estão dizendo que estão fazendo DDD quando não estão. Ok, entendi. Mas ele também argumenta que o uso de abstrações como as encontradas no DDD (agregados, repositórios, entidades de domínio, objetos de valor, serviços etc.) é desnecessário se elas estiverem sendo usadas apenas para suportar uma arquitetura injetada em dependência. Essa é a parte que eu não entendo (o que há de errado nisso). Talvez esse seja o argumento do homem de palha , pois o uso dessas coisas não é apenas para "construir uma linguagem em torno da injeção de dependência".
Matt
3
Greg está parcialmente correto: os padrões especiais no DDD não estão particularmente relacionados ao DI. No entanto, em meu livro, peguei parte da terminologia, particularmente a definição de Entidade x Objeto de valor x Serviço, porque é importante entender o que injetar onde. No entanto, tanto essa terminologia quanto outros padrões, como Repository e Factory, são muito mais antigos que o livro DDD, pelo que dizer que tais coisas são desnecessárias fora do DDD me parece incorreto. Pode depender de como você realmente define o DDD.
Mark Seemann
2

Aposto que Greg está se referindo ao aplicativo simples se houver um subconjunto de padrões de Design Orientado a Domínio, em vez de toda a abordagem DDD. O termo DDD-Lite refere-se implicitamente ao livro http://www.infoq.com/minibooks/domain-driven-design-quickly, que costumava ser popular entre os iniciantes em DDD, mas falha muito no cenário inteiro, concentrando-se apenas no padrões de projeto de modelagem local.

Embora a injeção de dependência seja considerada uma coisa boa, não existe uma forte correlação entre DDD e DI.

ZioBrando
fonte