Vi muitos e muitos tópicos sobre DDD aqui nesse fórum, mas são coisas de 9, 8 anos atrás…
Alguém ainda usa DDD em seus projetos?
Descobriram que é uma furada? Ou desistiram de tentar entender seus conceitos?
Por que ninguém mais fala sobre o assunto?
1 curtida
Talvez por uma maior disseminação do mesmo. Penso que o DDD é um conceito interessante, principalmente com o surgirmento dos micro serviços (microservices). Senão me engano, na QCon deste ano isso foi discutido e conversado. De qualquer forma, é preocupante quando se aplica um conceito, técnica ou algo do genêro por modismo.
O interessante é sempre avaliar quais benefícios ao time, produto e consequentemente à empresa alguma tecnologia e etc trará.
Abraço.
1 curtida
Complexidade desnecessária.
Hmmm, acho que isso depende da complexidade do domínio. Domínios complexos exigem técnicas mais sofisticadas. Você chegou a ter uma experiência ruim com DDD que queira e possa partilhar?
Funcionalidade complexa para o negócio não necessariamente precisa de solução técnica complexa. DDD pode ser útil para equipes que precisam seguir algo para ter uma forte disciplina. Como em fábricas de softwares, pela rotatividade, e grandes equipes em um único grande projeto totalmente acoplado, onde o caos fica por um fio. Já pequenas equipes dedicadas no cliente com sistemas bem divididos por focos de uso, se entendem e se organizam bem, sem precisar adicionar o que é chamado de “complexidade acidental”.
Que práticas de DDD vocês consideram que adicionam extra complexidade?
Tenho opiniao similar ao @nel: tantas coisas estao assimiladas no dia a dia que ninguém discute tanto mais.
Só por adotar DDD corretamente já é um extra. A questão é se você vai realmente precisar seguir essa abordagem.
Tudo tem que partir do que você atende de verdade. Ou ter um exemplo de caso que faça você buscar algo que vá te ajudar a resolver um problema provável, e não só ficar usando algo por ser tecnicamente bom, sem que seja essencial para resolver um problema.
Já assisti duas apresentações de DDD e pelo que falaram não vi nada que fosse agregar de positivo pra simplificar o desenvolvimento, pelo menos numa equipe coesa e auto disciplinar em projetos divididos. Enfim, considere no seu cenário o que nessa abordagem pode te trazer de saldo positivo, senão está adicionando complexidade técnica sem necessidade.
Eu concordo contigo que qualquer técnica extra que você aplique terá um custo.
Mas na sua visao, quais problemas DDD resolve?
Por que uma equipe coesa e auto disciplinar, com projetos divididos, elimina a necessidade de DDD?
A indústria parece ter evoluído da idéia de grandes sistemas OO para microservices então DDD precisa de um repaginada.
Exatamente.
Falei isso no meu segundo post, principalmente em relação a sistema único que vai ficando cada vez maior. Projetos imensos podem chegar a um ponto de se perder o controle, onde DDD força uma disciplina para tentar deixar as coisas no trilho. Fábrica de software também pode ser um exemplo para seguir a abordagem, pela rotatividade entre projetos e excesso de juniores.
Porque DDD, entre outras coisas, é uma forma de forçar o programador a seguir uma disciplina.
Com sistemas divididos você divide a complexidade do todo, sem precisar de uma forte disciplina com técnicas para atender o domínio do negócio, a qual DDD aborda.
Acho que a nossa diferença de opiniao a respeito de DDD é justamente porque temos idéias diferentes do que ele é ou o que ele resolve.
Entendo DDD como foco no domínio ao invés de focar na arquitetura e tecnologias, por exemplo.
Com isso você tem um código mais focado no negócio ao invés de abstraçoes técnicas, você fica mais alerta ao incluir regras de domínios diferentes juntas no mesmo lugar, etc.
Quanto a projetos grandes, o pessoal que promove microserviços, cita DDD como crucial, justamente por ajudar como quebrar serviços. Num sistema grande ou em serviços, o objetivo é ter as diferentes capacidades de negócio que seu sistema provê bem definidas.
Nao entendi a parte em que diz que força o programador a seguir uma disciplina. O que seria essa disciplina?
2 curtidas
@AbelBueno, tenho a mesma impressão que você. DDD não implica em grandes monolitos OO (e veja bem que MUITOS sistemas podem ser monolitos, nem tudo tem que virar micro serviço).
DDD tem o conceito de Bounded Contexts que é uma maneira de integrar diferentes sistemas OO cada um com seu modelo próprio.
Acho que o problema com DDD é que muita gente lê sobre Entity, Value Object, Repository, Factory, Service e para por aí.
1 curtida
Seguir um padrão de projeto é seguir essa disciplina.
Essencialmente não é necessário DDD para focar no negócio ou “domínio”. Mas as técnicas (não falo “tecnologia”) de DDD vão te forçar a seguir padrões para que isso ocorra. Então ok quem realmente precisa disso para atender bem o cliente.
Mesmo que não foque em “tecnologia”, essa abordagem pode incluenciar sim na arquitetura. Pelo menos um diagrama louco que me apresentaram na época mostrava isso:
Outro mais louco ainda que inclui esse bounded contexts (mais detalhado no post do colega @esmiralha):
@esmiralha eu pelo menos não disse que DDD implica em “grandes monolíticos”, mas ao tentar defender o mínimo sobre DDD, que ele poderia ajudar nesses casos mais complexos de administrar, onde esses “alertas” que o @AbelBueno podem trazer retorno contra o caos.
Vejo da seguinte forma: desenvolver software é um jogo colaborativo e todo jogo precisa de regras. As regras tem que ser claras, sucintas e não devem atrapalhar a atingir o objetivo do jogo. Nesse caso, o objetivo é entregar software que funciona e satisfaz o cliente.
Se não há nenhuma regra de design, cada um vai fazer da forma que achar melhor naquele momento, Quando eu for dar manutenção no seu código, terei maior dificuldade para entende-lo porque não sei bem o que esperar. Logo, não vou querer dar manutenção em código dos outros, só no meu, porque assim sou mais eficiente e não me meto em furada. Criam-se silos de informação, onde cada programador é dono do seu pedaço. As pessoas se aposentam ou mudam de emprego e aquele pedaço de código vira uma caixa preta onde está escrito: “Não mexa!”. Eu já vi esse tipo de situação tantas vezes…
Resumindo: “there must be rules”. Mas não necessariamente as regras de DDD ou dos DPs. Se você, junto com seu time, consegue elaborar um conjunto de “regras da casa” que funciona melhor que DDD ou DP no seu contexto, excelente! Mas, se você tem uma situação que não sabe resolver e alguém já possui uma solução que foi aplicada com sucesso, por que não se aproveitar disso?
1 curtida
Concordo. Como tinha falado, equipes pequenas trabalhando no mesmo local no cliente em projetos divididos podem se entender e serem coesas mais facilmente sem precisar seguir padrões propostos pelo DDD por exemplo, que na minha opinião é uma abordagem complexa.
Também concordo que algo motivado apenas por modismo é preocupante. Só fiz essa colocação no tópico porque não vejo mais falar tanto assim de DDD.
Mas tenho dúvidas em relação se o DDD está realmente disseminado e não confundido com algum tipo de regras de separação de camadas e padrões (tipo Repository, Domain Services, Application Services, Entities, Infra etc…)
Claro, perfeito sua observação.
a vantagem de DDD ter deixado de ser moda é que um bom profissional vai continuar usando as partes boas e vai adaptar as novas coisas que vem surgindo, enquanto a galera que usou DDD “por usar” vai estar usando alguma outra novidade ( como microservices em Go ).
assim como em gadgets, em desenvolvimento vc tem os early adopters e alguns, por razões comerciais vendem isso como uma bala (quase) de prata ( pq garante venda de software, treinamentos, palestras, etc ). a experiência vem pra identificar os padrões ( e surgem as expressões: isso é o novo Rails, etc ) e tentar evitar as armadilhas basicas.
Eu achei DDD bem impressionante ( pela simplicidade ) porém alguns problemas que eu tive ao interagir com outros times foi q se eu usasse os termos DDD rolava bastante revolta, mas se eu mudasse os termos eu conseguia o que eu queria ( é tipo vc chamar interface REST de “HTTP” ). Ai se vc faz uma pesquisa de causa-raiz descobre muitas coisas interessantes sobre a empresa ( e como as pessoas tem medo de serem demitidas ).
3 curtidas
Isso que você disse:
assim como em gadgets, em desenvolvimento vc tem os early adopters e alguns, por razões comerciais vendem isso como uma bala (quase) de prata ( pq garante venda de software, treinamentos, palestras, etc ).
esclarece muita coisa!
A idéia que todas as aplicações tem que operar baseado no mesmo conjunto de regras, é algo que satisfaz o cliente, ou a comunidade de modelagem de dados?
Estou imaginando se a regra é sistemas quebrados em “open host services” que seguem “separate ways” e não se integram (a não ser por meio de uma “published language”), sera que o cliente iria reclamar, ou os analistas, DBAs e arquitetos astronautas?
Desenvolvedores, com certeza, iriam adorar trabalhar com aplicações inteligentes que combinam dados de diferentes services, melhor do que otimizar query o dia inteiro… lol…