tentando aplicar os conceitos do DDD.

[eusoufeioedai 0]

Olá !!

 

Tenho algumas dúvidas sobre alguns item do DDD.

 

Fiz uma aplicação em Dot.Net e criei várias camadas(Aplicação, Domínio e Infra)

 

1-Como eu poderia realizar a persistência/Recuperação dos dados no banco de dados ?

Estaria incorreto em criar uma classe de serviço "persistenciaDeUsuario" e nela realizar

a validação/verificação dos dados e se positivo chamar a classe/metodo "new usuarioDao().Cadastrar(usuario)" e realizar a persistencia do usuário?

Quando eu quiser realizar uma atualização dessas informações cadastradas no banco eu chamaria um metodo da classe

do repositorio passando um id ex: RepositorioUsuario.BuscarUsuarioPorID(2) e após a edição das informações chamar novamente a classe de servico "persistenciaDeUsuario";

 

Na vida real eu pensei da seguinte forma. Quando uma pessoa vai realizar um cadastro para obter um cartão de crédito em um supermercado. O Cliente(Entidade) passa

os dados para a atendente(Serviço) e ela verifica se os dados estão faltando ou estão incorretos. Se estiverem faltando ou incorretos ela notifica o cliente, caso contrário realiza

o seu cadastro. O atendente sabe que existe um lugar em que ele pode passar os dados e realizar o cadastro. Ele só não sabe em que lugar essas informações são armazenadas.

 

 

 

 

 

 

 

é isso mesmo ?

[Maykonn 6]

Você disse que possui camadas de Domínio e Infra-Estrutura.

Tenho algumas perguntas:

 

1) Onde está seu acesso a banco de dados?

2) persistenciaDeUsuario está no Domínio ou na Infra?

 

Pelo que entendi lendo o livro de Eric Evans, a pesistenciaDeUsuario não deve ficar dentro do Domínio Principal, mas sim funcionar como um serviço a ele.

Na Infra teremos o acesso ao banco de dados, mas como uma Interface que deve ser implementada pelo Serviço.

 

Outro ponto: validação/verificação

Isso deve ser feito em um subdomínio genérico onde estariam as Políticas do negócio. E no Domínio o negócio em si.

 

 

Não posso afirmar se o que citei é correto pois também estou estudando esses conceitos. Mas é um excelente ponto para debatermos sobre o assunto.

[eusoufeioedai 0]

Olá !!!

 

 

 

O acesso a dados está na camada da infra. Eu criei algumas classes "dao" responsáveis pelo CRUD e consultas diversas

As classes de serviço eu coloquei no dominio. Nao sao interfaces. São classes concretas. Essas classes acessam as classes da infra, caso necessitem.

Os repositorios estao no dominio e não sao interfaces. São classes concretas que acessam as classes da infra.

 

 

Uma duvida que tenho é como eu poderia passar os valores de uma pagina web para o dominio.

ex.: tela de Login e Senha. Eu poderia passar os valores dos campos direto para a classe de servico "autenticar"(não é da responsabilidade do usuário

realizar a autenticação do sistema. Essa responsabilidade eu passo para uma classe de serviço) ou crio uma classe anêmica apenas para passar os valores do login e senha para a classe de servico ?

 

 

Eu sei que cada sistema tem uma regra de negócio diferente, mas eu fico perdido quando preciso persistir os dados formulario no banco de dados e depois recupera-los. Tendo essas dúvidas exclarecidas eu terei mais tempo estudando as regras de negócio dos sistemas.

 

 

 

Você disse que possui camadas de Domínio e Infra-Estrutura.

Tenho algumas perguntas:

 

1) Onde está seu acesso a banco de dados?

2) persistenciaDeUsuario está no Domínio ou na Infra?

 

Pelo que entendi lendo o livro de Eric Evans, a pesistenciaDeUsuario não deve ficar dentro do Domínio Principal, mas sim funcionar como um serviço a ele.

Na Infra teremos o acesso ao banco de dados, mas como uma Interface que deve ser implementada pelo Serviço.

 

Outro ponto: validação/verificação

Isso deve ser feito em um subdomínio genérico onde estariam as Políticas do negócio. E no Domínio o negócio em si.

 

 

Não posso afirmar se o que citei é correto pois também estou estudando esses conceitos. Mas é um excelente ponto para debatermos sobre o assunto.

[Maykonn 6]

O acesso a dados está na camada da infra. Eu criei algumas classes "dao" responsáveis pelo CRUD e consultas diversas

As classes de serviço eu coloquei no dominio. Nao sao interfaces. São classes concretas. Essas classes acessam as classes da infra, caso necessitem.

Os repositorios estao no dominio e não sao interfaces. São classes concretas que acessam as classes da infra.

 

 

Na minha opnião está certo sim. E eu faria assim também num primeiro momento mas depois apenas iria separar Serviços de Aplicativo dos Serviços de Domínio, ou algo assim. Porque penso que os Serviços de Aplicativo - DAOs por exemplo - não fazem parte do Domínio.

 

 

Uma duvida que tenho é como eu poderia passar os valores de uma pagina web para o dominio.

ex.: tela de Login e Senha. Eu poderia passar os valores dos campos direto para a classe de servico "autenticar"(não é da responsabilidade do usuário

realizar a autenticação do sistema. Essa responsabilidade eu passo para uma classe de serviço) ou crio uma classe anêmica apenas para passar os valores do login e senha para a classe de servico ?

 

 

Olha, eu passaria primeiro por uma Camada de tratamento HTTP, e então para alguma classe que soubesse o que a requisição deseja fazer, por exemplo autenticar um usuário, e finalmente essa classe iria instânciar a Classe Autenticar realmente.

Tudo isso no Serviço de Aplicativo. Algo paralelo ao Domínio.

 

 

Eu sei que cada sistema tem uma regra de negócio diferente, mas eu fico perdido quando preciso persistir os dados formulario no banco de dados e depois recupera-los. Tendo essas dúvidas exclarecidas eu terei mais tempo estudando as regras de negócio dos sistemas.

 

Essa também, ainda, é minha maior dificuldade utilizando o DDD.

E essa imagem ainda me faz pensar um pouco: