Em “controllers” coloco classes que vão receber dados e acionar models e/ou renderizar views.
Nos “models” coloco basicamente as entidades do banco de dados e suas operações.
Em “views” coloco as páginas com código html + php para exibição de dados
No “core” coloco classes e/ou arquivos genéricos (tenho planos de usar essa mesma base para desenvolver outras aplicações futuramente, uma espécie de microframework.)
No entanto surgiu duas classes um pouco diferentes, uma delas trabalha com datas e realiza operações como conversão e cálculo entre datas, a outra cria e gerencia múltiplas threads. Tenho dúvida em qual camada devo colocá-las, já que nenhuma delas fazem acesso a banco de dados ou arquivos e nem emite saídas, apenas retornam valores.
Devo criar uma camada adicional? Qual?
Devo colocá-la em um das camadas já existentes?
Obs: qualquer informação adicional que possa ser útil é sempre bem-vinda!
Esse post no blog dele dá uma noção, e no livro Clean Architecture ele elabora mais sobre o tema.
Resumindo, a ideia é que as pastas/modulos/arquivos mais “top-level” do seu sistema não deveriam refletir a técnica/framework que você utiliza para organizar os blocos da solução, mas sim deveriam refletir os módulos do sistema.
Por exemplo, se você está fazendo um software para controlar uma empresa de transportes, ao invés de ter as pastas/módulos “domain”, “controller”, “view”, etc., você deveria ter pastas separadas como “account”, “client”, “scheduling”, “booking”, etc. Dentro desses módulos você pode criar mais separações (como “domain”, “infra”, “controller”, etc.) como achar melhor.
O livro “Domain-Driven Design” fala bastante sobre isso. Operações que não cabem em modelos podem ser implementadas em classes de serviço. Classes de serviço fazem parte do modelo.
Já tenho grande parte da aplicação construída, não pretendo restruturar as camadas de toda aplicação. A minha ideia seria criar uma nova camada ou subcamada ou usar uma camada já existente. Andei pesquisando e vi que poderia ser adicionada uma camada “Service” mas ainda não sei se é adequado.
É adequado quando necessário, caso contrário o desenvolvimento fica burocrático. O mais importante é não misturar funcionalidades. Se vai que salvar um registro no banco, será um php que só vai fazer isso, outro pra consultar no banco, validar, etc. As views separadas também. Sempre tudo agrupado como colega falou acima, por módulo, falando a mesma língua do cliente.
Releia o tópico, pense nas duas classes que citei, pense agora que você precisa colocá-las em alguma camada. Qual delas você colocaria? Ou criaria uma nova camada?
Está falando disso? Se for, está muito vago. Trabalhar com data, operação de conversão e multithread pode ter em vários lugares. Faltou o contexto, o que precisa resolver de fato pro Negócio.
Se eu te disser que tenho uma classe “pessoa”, com atributos “nome, cpf e endereço” e que preciso gravar tais dados no banco, provavelmente você vai me dizer para colocá-las no model.
É simples, da mesma forma que seu eu te disser que tenho uma classe complexa que faz vários cálculos envolvendo datas e outra mais complexa ainda que cria e gerencia muitas threads, onde me diria para colocá-las?
Você sempre responde todos os tópicos deste fórum, e na maioria das vezes não esclarece/acrescenta nada. Tenho a impressão que você só responde para parecer “bichão/sabichão”.
Se isso fosse verdade não teria ajudado a resolver muitos tópicos. A maioria agradece, não estou preocupado se não agrado alguns.
Neste caso pode agrupar como “Service”, “Business Process”, seja lá o que for, mas que seja uma classe que tenha a responsabilidade de resolver somente esse problema, sempre lembrando de agrupar pelo módulo antes.