Considerando que o domínio não depende de ninguém, que trabalha somente com suas classes e nada mais, porém que ainda temos que lidar com os dados que vem de alguma forma do usuário e geralmente persisti-los em algum lugar, e ao mesmo tempo deixar isso imperceptível para quem trabalha com as classes do domínio, pergunto:
Era possível fazer isso até, digamos, 5 anos atrás? É possível fazer DDD puro com tecnologia antiga? É possível fazê-lo sem injeções de dependências?
bom para fazer esta separação vc precisa usar o conteito de interface… por exemplo se quiser que seu domínio não conheça absolutamente nada de quem implementa o repositorio…
então a resposta é sim… vc de alguma forma antigamente ia criar uma classe que implementa alguma interface, talvez usando o padrão factory… injeção de dependências é só a forma moderninha…
por exemplo vc coloca um @MinhaClasseAqui ou @MeuEJBAqui e bingo…
Considerando que o domínio não depende de ninguém, que trabalha somente com suas classes e nada mais, porém que ainda temos que lidar com os dados que vem de alguma forma do usuário e geralmente persisti-los em algum lugar, e ao mesmo tempo deixar isso imperceptível para quem trabalha com as classes do domínio, pergunto:
Era possível fazer isso até, digamos, 5 anos atrás? É possível fazer DDD puro com tecnologia antiga? É possível fazê-lo sem injeções de dependências?[/quote]
Bom, já que fui citado… so quero esclarecer que nem o artigo nem o problema em foco é DDD. DDD é uma filosofia particular que assenta em Orientação a Objetos e no conceito de Dominio, mas que que lhe acrescenta outras coisas e visa simplificar a comunicação entre tem que desenvolver e quem tem o conhecimento das regras. “Fazer DDD” não faz sentido. Como toda a filosofia ou se segue, ou não. Seguir DDD só é possivel depois que o DDD foi definido, é como torcer para um clube. Só pode torcer depois que o clube existe.
Orientação a Objetos e Dominio são concietos antigos, logo sim seria possivel à 5 anos.
Tlv não acredite quando lhe disse isto, mas EJB é uma tecnologia orientada a dominio e tem mais de 5 anos.
O ponto não é se é possivel, mas se seria possivel com a mesma simplicidade que é hoje. O proprio EJB mostra que a simplicidade foi ganha com o tempo, mas isso poderiamos atribuir a um exagero no design original do EJB.
Acho que os avanços na metalinguagem do java e outras linguagens OO foram os que reais motivadores para a volta ao paradigma de pensar primeiro no dominio e depois no resto. È que o domino não são classes, as classes são as representações do dominio. O dominio é abstrato. Os metadados das classes são mais proximo do nivel de abstração do dominio e por isso, quanto a mim, que quanto mais a metalinguagem (reflection, annotations, etc…) evolui mais facil é construir um modelo e implementação do dominio.
Esse resto da aplicação é normalmente muito igual - cheia de requisitos não-funcioanis - e até por isso existem um bando de frameworks para auxiliar e aumentar a produtividade e o dominio pode brilhar de novo.
[quote=sergiotaborda] (…)…
[i]Acho que os avanços na metalinguagem do java e outras linguagens OO foram os que reais motivadores para a volta ao paradigma de pensar primeiro no dominio e depois no resto. È que o domino não são classes, as classes são as representações do dominio. O dominio é abstrato. Os …
[/quote]
“Java incorporou novas features, metalinguagem é um proposito de aspecto e quebra o paradigma da Orientação a Objetos, indo para uma POA”
A programação orientada a aspectos tem como objetivo a separação do código segundo a sua importância para a aplicação, permitindo que o programador encapsule o código secundário em módulos separados do restante da aplicação.