Entrar Ainda não tem acesso?
Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas

repository dentro de Domain e de InfraStructure

Referente ao curso PHP e PDO: trabalhando com bancos de dados, no capítulo Boas práticas e atividade Implementação do PdoStudentRepository

por Ivan
| 479.4k xp | 139 posts

Dentro de InfraStructure não seria melhor usar uma pasta chamada Service em vez de duplicar Repository? Acho estranho ter duas pastas com o mesmo nome... Ou isso fere algum padrão ou boas práticas?

Pensando em implementar formulários nesse projeto para preencher campos na tela e persistir no Banco, uma outra dúvida:

Criar uma pasta para os Controllers, essa pasta ficaria dentro do Domain ou logo abaixo do src ?

Os formulários html ficariam em uma pasta chamada public, na raiz do projeto?

E os arquivos auxiliares como js, css e bibliotecas ficariam dentro de InfraStructure ?

Pensei em uma strutura assim:

PHP-PDO
  src
      Domain (Classes para Persistir)
      Repository (Interfaces)
      Service (Implementação das Interfaces Repository e alguma regra do negócio)
      Controller (Controladores para páginas HTML, chamando os serviços)
  resources
      static
           css
           images
           js
           vendors (caso use bootstrap)
      templates
           fragments
           students (páginas html)

Essa estrutura estaria correta ou teria algum erro conceitual? A pasta template deveria se chamar public ? Se puder dar essas dicas conceituais seria ótimo!

referência:

04 Boas práticas - 07 Implementação do PdoStudentRepository

Até qui, ótimo treinamento, parabéns!

3 respostas
por Vinicius Dias
| 2870.7k xp | 4248 posts
Instrutor Zend Certified PHP Engineer

Fala, Ivan.

A dúvida ficou bem confusa mas vou tentar elucidar alguns pontos:

  1. O nome Service não traz nenhum significado pro negócio. Ter uma pasta com esse nome tende a sacrificar a legibilidade e a arquitetura
  2. A pasta de infraestrutura "dá vida" pra determinados pontos do domínio, logo, faz todo sentido ter a pasta com o mesmo nome.
  3. No caso de ser uma aplicação web, há várias possíveis abordagens. A mais simples é criar uma pasta Web ou Apresentacao e nela utilizar uma estrutura semelhante ao MVC, por exemplo.
  4. Você escreveu Domain (Classes para Persistir). Isso não faz sentido. O domínio do negócio é muito mais do que apenas persistir. Toda regra de negócio está no domínio, não apenas lógicas de persistência
  5. Sugiro o estudo mais aprofundado sobre Clean Architecture, Arquitetura Hexagonal, DDD, etc. Nessas leituras você vai encontrar mais respostas sobre como arquitetar sua aplicação

:-D

Espero ter ajudado, Ivan. Forte abraço e bons estudos.

por Ivan
| 479.4k xp | 139 posts

1 e 2 - realmente fiquei com dúvida sobre o repository na infra e no domain. Mas entendi que não tem problema.

3 - era isso que eu estava pensando em fazer nesse treinamento. Colocar no formato MVC, vou usar essa abordagem web.

4 - é que as classes que representam as tabelas do Banco ficam nessa pasta domain. Então caso precise serar da classe, criaria dentro do Domain também.

5 - obrigado pelas dicas, vou anotar e procurar.

Ajudou bastante, muito obrigado!

#quarentenaEstudo

solução!
por Vinicius Dias
| 2870.7k xp | 4248 posts
Instrutor Zend Certified PHP Engineer

Então, Ivan. Sobre Repository:

No domínio você define o que precisa ser feito. Na infraestrutura você define como vai ser feito. Doctrine, Pdo, Eloquent, RedBean, etc. Isso tudo é indiferente pro domínio, entende?

Sobre o ponto 4:

"as classes que representam as tabelas do Banco"

Nesse ponto tem um problema de como você tá enxergando o sistema. Um banco de dados é só um sistema de apoio. É um mero detalhe pro sistema. Suas classes não representam tabelas no banco. É o contrário. O banco de dados pode armazenar suas classes, assim como você pode armazenar em arquivos, memória, bancos não relacionais, etc. No estudo sobre DDD isso talvez fique mais claro.

PS.: Se as dúvidas tiverem sido solucionadas, não esquece de marcar o tópico aqui como solucionado. ;-)