Arquivo Discussoes de Programacao e Tecnologia Pessoal, já pesquisei bastante e ainda continuo com uma dúvida em relação a simples operações CRUD com DDD, de qual forma eu faço a persistencia de um objeto no sistema
Obrigado!
Olá
Acredito que, para simples CRUDs, a terceira opção é a mais adequada. Como não há muita lógica envolvida, o facade - que fica na camada de aplicação - pode muito bem acessar o repositório diretamente para persistir a entidade.
Na verdade, se o sistema for bastante simples, até mesmo a existência da camada de aplicação é questionável.
Opa amigão!
Olha, eu penso o seguinte…
Ter a sua aplicação dividida em services, entiies, repositories, etc… não significa que você tem um design orientado a domínio.
DDD se refere à maneira como você representa o seu domínio em forma de programação. Aliás, DDD não está restritamente ligado à OO (apesar de sabermos que OO é a melhor maneira de alcançar o state of the art do DDD).
Quanto à sua dúvida, não existe a arquitetura correta para implementar as interações entre as suas camadas… depende muito do caso onde será aplicado.
Mas pra não ficar a impressão que eu falei um monte e não ajudei nada (é… eu também estou com essa impressão…), deixa eu dar uns pitacos com relação aos exemplos que você mandou…
Depende do que você está chamando de camada view… Se você estiver se referindo à sua jsp, não acho aconselhável… se estiver se referindo ao seu Managed Bean (está usando JSF?), pode ser uma maneira sim. Em JSF nada te impede de tratar o seu MB como um façade pro seu domínio…
Camada View -> Service -> Repository
Camada View -> Facade -> Repository
Aliás, pensando nisso me surje uma dúvida que, espero, alguém mais capacitado irá nos ajudar…
Um Service pode ser visto como uma espécie de Façade?
Quero deixar claro que também estou tentando me situar neste mundo mágico do DDD, então isto aqui é apenas a MINHA visão que pode conter - provavelmente contém - algumas ranhuras…
…de vagarinho a gente chega lá
Um abraço!
CRUD e DDD é quase um oximoro.
Pessoal, já pesquisei bastante e ainda continuo com uma dúvida em relação a simples operações CRUD com DDD, de qual forma eu faço a persistencia de um objeto no sistema
- Camada View -> Repository
- Camada View -> Service -> Repository
- Camada View -> Facade -> Repository
Obrigado!
Sem muito a acrescentar ao que o frocchagas ja disse…
Na pratica eu uso a opcao 1) pra Cruds simples (usando JSF), quem invoca o respositorio eh o managed bean. Mesmo assim, talvez melhor fosse a 2 ou a 3 pro caso de voce precisar implementar em outra tecnologia, assim nao precisaria alterar nada. Apesar de que, como sao CRUDs simples, o trabalho seria bem pouco.
Resumindo: acho que qualquer uma das tres é valida.
Aliás, pensando nisso me surje uma dúvida que, espero, alguém mais capacitado irá nos ajudar…
Um Service pode ser visto como uma espécie de Façade?
Desenterrando um post antigo, porque o achei em uma consulta no google. =)
Aliás, pensando nisso me surje uma dúvida que, espero, alguém mais capacitado irá nos ajudar…
Um Service pode ser visto como uma espécie de Façade?
Há dois tipos de Services Layers aceitáveis: Domain Facade e Operation Script.
O Domain Facade é uma fina camada de facades que determina os limites de território do Domain.
O Operation Script, são classes que encapsulam operações do Domain e contém lógica. Tá mais pra um decorator.
Ambos são bem simples tecnicamente, o problema consiste em determinar quais são as operações que serão disponibilizadas por estes services. Daí a grande necessidade de entender o que realmente é o Domain Driven Design.
Simplicidade:
View -> Repository
Galera estou com uma dúvida sobre a questão de dependencia entre as camadas.
Eric, em seu livro, diz que devemos utilizar alguns padrões citados no mesmo para resolver os problema de coesão e dependência entre as camadas, seguindo a ideia de dependencia vertical de cima para baixo (interface --> application --> domain --> infraestrutura). A dúvida:
Como podemos implementar um Repositorio (na Infra) sem depender das Entidades (no dominio)?
Um repositório não pertence à infra, e sim, ao domínio. Ele pode depender da infra pra realizar suas tarefas.
Um repositório não pertence à infra, e sim, ao domínio. Ele pode depender da infra pra realizar suas tarefas.
Não disse que Repositorio é da Infra e sim sua implementação:
Mas beleza, estamos concordando até aqui… o lance está em:
como implementar o repositorio na infra sem que ele dependa do domínio?
vlw novamente tnaires
Vamos continuar a discussão no tópico original:
http://www.guj.com.br/posts/list/145822.java
vlw e obg.
vamos outro…
Um repositório não pertence à infra, e sim, ao domínio. Ele pode depender da infra pra realizar suas tarefas.
Não disse que Repositorio é da Infra e sim sua implementação:
Mas beleza, estamos concordando até aqui… o lance está em:
como implementar o repositorio na infra sem que ele dependa do domínio?
vlw novamente tnaires
O repositório faz parte do domain model, cuida do ciclo de vida dos objetos de domínio. Dessa forma, não existe repositório se nào existir objetos de domínio. Consequentemente, o repositório depende dos objetos de domínio.
Quanto a isto nenhuma dúvida. A dúvida é:
Creio que o raciocínio está correto. O que está errado é manter o repositório fora do modelo de domínio, conforme foi falado no tópico.
Creio que o raciocínio está correto. O que está errado é manter o repositório fora do modelo de domínio, conforme foi falado no tópico.
Não lembro de alguem ter falado isto, mas blz. Repositorio fica no dominio, pelo menos no meu entendimento.
Voltando ao raciocinio, então significa que a arquitetura em camadas defendida por Evans, como segue abaixo, não foi seguida por ele mesmo quando implementou o projeto para demonstrar a aplicação de DDD: http://dddsample.sourceforge.net/ :
Então agora eu começo a pensar:
a arquitetura defendida por DDD é impraticavel?
Qual sua opnião sobre isto? Se alguem mais quiser fazer alguma colocação…
vlw cabra t+
tnaires, desculpe-me
percebi agora que o tópico já tinha outros posts. Outra, não tinha percebido que era você e que já discutimos isto no outro tópico.
Vlw cabra e obrigado!!
Normalmente depende da estratégia de persistência que você utilizar a forma que isso será feito. Mas a camada de infra pode depender da camada de modelo.