O problema do Bauer é que ele não entendeu repositórios (o outro post não fala exatamente sobre DDD mas é apenas uma crítica ao Uncle Bob, pelo que lembro). Basta ver como ele refuta grosseiramente os argumentos contrários à sua idéia.
Quem frequenta o forum do Hibernate ou este blog há algum tempo sabe que não entender algo nunca foi pré-requisito para criticar
Se DDD é uma furada, então OO também é… na minha concepção DDD que é OO “de verdade”.
O pior é que é tão dificil fazer os desenvolvedores (e até arquitetos) entenderem isso… o pessoal acha que porque usa java esta programando OO, mas na maioria dos casos parece que existe uma barreira na mente das pessoas que diz:
Entity não pode ter lógica
Separe sua lógica em serviços que manipulam os entitys
Já vi bastante arquitetura que acredita ser OO apenas porque os entitys usam herança, polimorfismo, etc, porem a logica é implementada em serviços separados.
Eu vivo comentando que ejb3 não eliminou a necessidade da DI do Spring por não fazer DI em entity… e alguns me respondem que se pretendo injetar alguma coisa nos entitys então tem algo errado com o design… :shock: e por aí vai…
Agora DDD não é bala de prata… é preciso analisar quando vale a pena utilizar. As vezes um transactionScript pode resolver seu problema muito mais rápido (dependendo da complexidade).
Para tudo há prós e contras… não podemos generalizar e dizer que DDD ou TransactionScript é furada. Tudo depende do contexto.
[quote=Leonardo3001]
Esse livro é bom? Ou tem algo mais “Head First”? Só há algum tempo eu ouvi falar de DDD, e eu gostaria de ler algum livro sobre o tema.[/quote]
Este é muito bom:
Apesar dos exemplos serem em .NET (C#), fala sobre o ciclo completo e também abrange muito sobre TDD. É uma oportunidade de aprender DDD, C# e TDD.
Esse livro é bom? Ou tem algo mais “Head First”? Só há algum tempo eu ouvi falar de DDD, e eu gostaria de ler algum livro sobre o tema.[/quote]
É a referência na área.
Acho que agora bem que Eric Evans ou outro defensor (com nome) de DDD poderia escrever uma resposta. A algumas semanas Gaving King ficou P*to pq fizeram uma comparação do Hibernate com Active Record e o autor não usou algumas das novas features do Hibernate 3.
Posta alguma coisa no seu blog em inglês Shoes…e coloca la o endereço no trackback do blog do Bauer.
O problema do DDD eh q eh visto por muitos como o calice sagrado, aquilo q contem toda a essencia das coisas.
Todo mundo pensa - assim com eu pensei - que ia comprar o livro, ler em uma ou duas semanas e depois ligar pro Evans e pro Fowler pra marcar uma cerveja e discutir o futuro do desenvolvimento de software. E nessa o neguinho quebra a cara.
DDD eh dificil pacas. Nao eh uma descricao de patterns (embora tenha alguns). Ele ensina a vc ficar atento a algumas coisas pra descobrir um design melhor, mas nao te ensina um design melhor pro teu problema (e nao teria como, afinal eh teu problema). Eh dificil, complexo e com exemplos q vc nao consegue facilmente transportar para o seu dia-a-dia. Vc tem q ler e reler e reler e aos poucos vc vai pegando uma coisa aqui e outra ali.
E que Deus abençoe o DDD, o avanço natural do desenvolvimento OO.
A minha única crítica ao DDD é que acho ele pouco acessível. Incrível como coisas bizorrêscas como Entity Beans conseguiu se difundir tão rápido e contaminar a cabeça dos programadores enquanto DDD e princípios básicos de OO mal conseguem sair do lugar.
Se por um lado DDD é ótimo, por outro lado ler o livro do Evans demanda alguma certa paciência (ou QI, rsrs), tornando o processo de ‘re-aprendizagem’ um tanto doloroso. Falta algum material mais mamão com açúcar. Algo que seja tão convincente quanto o material que convenceu a galera a abraçar os maleditos Entity Beans.
E aproveitando pra desabafar, não é por nada não. Acho que a galera do .Net neste assunto está bem na frente da galera do java, hehe. Essa sugestão de aprender C#, TDD e DDD pode ser uma boa.
[quote=Thiago Senna]
E aproveitando pra desabafar, não é por nada não. Acho que a galera do .Net neste assunto está bem na frente da galera do java, hehe. Essa sugestão de aprender C#, TDD e DDD pode ser uma boa. [/quote]
Thiago, cara, desculpe, mas isso que você falou é um completo absurdo. Não conheço todos os programadores .Net, mas estou no mercado, tenho muito contato muito grande com os alunos e não vejo a comunidade .Net, pelo menos aqui no Brasil, buscar DDD.
Não vejo a Microsoft defender o uso de DDD para .Net, simplesmente pelo fato dela não fornecer ferramentas que facilitem DDD na plataforma (não que não seja possível).
[adicionado] Digo isso porque a comunidade .NET aqui no Brasil ainda está na barra da saia da Microsoft, mas não todos [/adicionado]
Não sei como os desenvolvedores .Net aqui no Brasil vêem o DDD, mas lá fora tem uma turminha da pesada interessada no assunto, pelo menos, é o que parece.
Quanto a Microsoft dar suporte a DDD, acho que isso ainda não rola. Talvez o DDD seja um vocabulário de alguns bons programadores .Net que geram conteúdo sobre o assunto.
Quando ao blog mensionado: não ha como aceitar a critica de alguem que não entende o que é DDD, mas podemos aceitar a critica que o pessoal de DDD não explica , ou não evoluiu, os conceitos até ao ponto de vermos blogs com exemplos simples de uso de DDD.
Estas perguntas abaixo são realmente o cerne do DDD e várias vezes originaram threads aqui.
Independentemente de como implementar DDD ( tem gente ai usando EJB para implementar DDD) o que interessa são os conceitos que DDD trás. O conceito de entidade é muito igual ao do EJB , a implementação é que é diferente. Os conceitos mais “novos” e que marcariam alguma evolução são os de: Aggregation (Aggregado) e Specification ( Especificação). O primeiro é uma abstração acima de entidade e o segundo é uma forma de codificar regras.
O Repositorio não é “le piéce de resistance” do DDD mas apenas um artetato necessário ao introduzir Aggregation
(
what problem does it solve ? : Constroi agregados
how do I tell when I need to use it? Quando usar Agregados
)
O conceito de agregado é na realidade velho. Agregado é um nome especificio para ressaltar a natureza de grafo de uma entidade e o controle que ela exerce sobre os outros objetos a si subjugados. É só isso.
Se DDD é uma furada ?
Se vc ler o livro do Evans vc vai achar que é. Várias vezes é mencionado que criar um domain é um processo demorado ( de vários meses) e que mesmo com refactoring é um processo de tentativa e erro. Eu associo isto mais ao uso que ele faz do DDD do que propriamente à filosofia do DDD em si. Afinal se vc contar com experts de dominio que sejam bons comunicandores e vc não for completamente burro, construir um dominio não é tão dificil. O problema é contruir um dominio flexivel que atenta a todos os requisitos - até mesmo aqueles que o dono do negocio ainda não pediu.
A filosofia DDD não é uma furada, mas a sua implementação generica é muito mais dificil do que os autores deixam transparecer. Se usar DDD num programa standalone, é uma maravilha. Mas quando começam a entrar requisitos fortes de arquitetura a implementação naive deles começa a sofrer. A solução disso, do ponto de vista deles é simplesmente refactorar, mas convenhamos que existe um tempo limite e refactorar ad infinitum não é uma estratégia aceitável.
Para mim a parte mais difícil de se lidar com DDD é definir o real Core of Domain (capítulo do Evans).
Em um sistema grande, onde o usuário final pode interagir com diferentes parâmetros da aplicação que modifica os comportamentos das entidades… a fronteira entre aplicação e domínio, é muito tênue.
É verdade, eu sempre trabalhei no .Net usando NHibernate, Spring.Net, DDD, NUnit, etc. De vez em quando eu respondo alguns anúncios de emprego pra .Net só pra ver o que acontece quando eu falo que nunca associei um DataSet a um DataGrid diretamente… estranhamente nunca me chamam pra uma segunda entrevista…
Mas se você não usar DDD, como programar orientado a objetos ? BOLOVO ?
Eu recentemente tiver a opotunidade de usar DDD deste o início em um novo projeto e posso garantir, o tempo gasto na modelagem do Domain no inicio do projeto se pagou várias com a economia de tempo na implementação do restante do projeto.
E os refectoring no Domain no decorrer do projeto não foram nada traumatizantes.
…
e por aí vai…
