Arquitetura de Software - Cakephp 3

[rockrgo 138]

Boa tarde pessoal,

 

estou com uma dúvida sobre o framework cakephp 3, seria mais uma dúvida de arquitetura.

Atualmente a aplicação aqui da empresa possui suas regras (Envio de emails, logs, etc) todas no controller, porém os métodos dos controllers acabam ficando muito grandes. Como vamos refatorar algumas coisas e implementar funcionalidades novas, estavamos discutindo sobre este assunto.

 

Na opinião de vocês como é melhor implementar estas regras da aplicação?

 

Já utilizei o Zend e com ele eu tinha uma camada de Serviço (Service layer), onde pensei em implementar no Cake, mas não sei se seria o correto. Já li diversos artigos dizendo que as regras devem ficar no model, mas também não acho correto o model ficar responsável em disparar o envio de email e também acabaria ficando um Model enorme. Então estou nesse dilema, espero que possam me ajudar a clarear um pouco a mente.

 

Valeu, fico no aguardo

[srmacedo 66]

É um único controller para tratar de envio de email, gerar logs e etc?

E sim, seria totalmente errado deixar uma classe model ser responsável por essas responsabilidade.

[Williams Duarte 431]

11 horas atrás, rockrgo disse:

Já utilizei o Zend e com ele eu tinha uma camada de Serviço (Service layer), onde pensei em implementar no Cake

Camada Serviços não é inerente ao Zend Framework, é um Design Pattern,  e como o cake 3 implementa PSR-4 nada lhe impede de usar, claro que no cake2 isso é um pouco mais complexo, mas não é o caso do Cake 3.

 

11 horas atrás, rockrgo disse:

Atualmente a aplicação aqui da empresa possui suas regras (Envio de emails, logs, etc) todas no controller, porém os métodos dos controllers acabam ficando muito grandes. Como vamos refatorar algumas coisas e implementar funcionalidades novas, estavamos discutindo sobre este assunto.

A única responsabilidade do controller é transacionar dados, envio de email e logs são eventos que ocorrem na aplicação, mesmo em MVC não é responsabilidade do controller e muito menos da model disparar estes eventos, ai que entra o Pattern Service Layer, que é responsável por carregar estes objetos. Carregar é diferente de incluir toda a logica dentro.

 

11 horas atrás, rockrgo disse:

Já li diversos artigos dizendo que as regras devem ficar no model, mas também não acho correto o model ficar responsável em disparar o envio de email e também acabaria ficando um Model enorme.

Depende de Qual Model você está se referindo, MVC ou DDD?, se for dos conceitos da arquitetura DDD - "Domain-Driven Design", O correto é na Pasta Model in Domain ter estes agregados.
 

Citar

 

Domain/

      Model/ (camada do domínio)
               Payments/ (domain aggregate)
                         Payment.php (domain entity/aggregate root)
                         PaymentService.php (domain service)
                         PaymentRepository.php (repository contract)
                         PaymentLineWasAdded.php (domain event)

 

                       
Detalhe  MVC não resolve todos os problemas de arquitetura, somente ajuda organizar melhor o seu código, senão ainda teríamos os códigos spaghettis da vida. Mas os padrões estão ai para serem usados, e resolver problemas de design. 

[rockrgo 138]

@Williams Duarte desculpa é que não me expressei muito bem, sei que Service layer é um pattern, é porque no Zend eu tinha mais liberdade para implementar, por isso o exemplo dele.

 

Valeu cara, já clareou um pouco mais as ideias aqui. Vou tentando implementar aqui e qualquer dúvida volto a postar no fórum.

 

Obrigado