Além do MVC [Pt.02] — Camadas

Este post foca no uso do MVC no back-end web.

Leia a parte 01 (Além do MVC [Pt.01] — Qual o problema do MVC?)

Sou desenvolvedor web, então as camadas que vou citar fazem mais sentido em projetos web mais comuns, principalmente em projetos PHP.

Muitas dessas camadas são pautadas no S de SOLID (Single Responsibility). Elas possuem apenas um objetivo, uma responsabilidade.

I/O — Entrada e saída

Geralmente contempla a camada HTTP da aplicação.
Basicamente controllers passaram a ser divididos em quatro camadas:
Routes — Middlewares — Controllers — Actions

Rotas podem ser velhos conhecidos de muitos, já middewares não. Eles são o meio de campo entre a entrada e a saída de dados, são geralmente aplicados nas rotas porém podem ser aplicados diretamente nos controllers também.

I/O não se aplica apenas a HTTP, essa camada é aplicável a qualquer tipo de sistema. Em um CLI, ele pode ser caracterizado com o interpretador dos comandos.

É muito importante entender que essa camada é “burra”, ela sabe muito pouco sobre a aplicação em si e as regras de negócio. Tudo que ela deve saber é a quem perguntar ou repassar os dados.

Regras de negócio

A camada mais importante e delicada da aplicação.
É nessa parte que os ânimos se levantam, há muitas discussões sobre como essa camada deve ser. O modelo que descrevo é o que eu uso na maioria dos meus projetos, porém ele varia com o tamanho e complexabilidade do projeto.
Sendo assim, entenda ela como uma recomendação, não como regra ou lei.

Repository — Services — Models (Database)
Como dito antes a camada de I/O deve ser o mais “burra” possível, tudo que ela sabe é quem chamar para executar as regras de negócio. E na medida do possível nunca, interagir com a database.

Repository fica com a maior parte da comunicação com a database, fazendo a leitura e escrita com o auxilo dos models, aqui você pode entender um pouco mais sobre repositórios.

Services pode confundir a mente de alguns desenvolvedores, afinal é um pouco difícil definir o que é um serviço. Eu costumo dizer: Serviços são classes especializadas.
Seguindo essa premissa, repositórios também são serviços, porém não caia na armadilha de criar um serviço que funcione apenas como intermediário para um repositório.
Classes de serviços são para ações mais complexas, como o processo de criação de um cliente.

- Criar o registro no banco de dados central
- Criar o banco de dados do cliente
- Rodar as migrações
- Dar a primeira carga de dados
- Enviar e-mails de para as pessoas envolvidas no processo

Um procedimento complicadinho né?

A action do controller responsável por isso teria seu código parecido com isso:

Em uma arquitetura de serviços cada passo do processo é um novo serviço, que pode ser enviado para uma fila, aguardando sua vez de ser executado.

ClientCreate é um serviço que cria o registro de cliente na database central, e adiciona um comando para a criação de um novo database em uma fila.
O comando de criação chama o serviço que cria a database, e após isso o mesmo comando pode adicionar outro comando, o de rodar as migrações. Um ciclo de comandos até todo o procedimento terminar.

Há serviços especializados apenas nesse tipo de procedimento.

Programar é pegar um problema grande e dividir ele em problemas menores, especializados. Com isso em mente fica fácil entender e aplicar serviços.

Models é outro ponto polêmico. Para fins práticos, vamos assumir que models são representações de entidades no banco de dados (eles são mais que isso ok?)

Na prática a camada model é nosso ORM ou Active Record.
A recomendação aqui é não deixar essa camada ser manipulada no controller ou na view. Novamente, não caia na armadilha de fazer uma camada de abstração total dessa camada, afinal ela é muito útil. Deixe a maior parte da sua manipulação no repository, e evite manipular ela nos seus services.

Já na view, você pode tirar proveito da camada de apresentação. É muito simples de utilizar.

O objetivo é ter o mínimo de regras na view, mesmo que sejam regras de apresentação.

Não sou cientista da computação, muito menos quero ficar criando siglas para seja lá qual for o design pattern que essas camadas se aplicam. Meu objetivo é fomentar seu pensamento crítico sobre a estrutura do seu projeto e as decisões que você tem tomado.

Não é todo projeto que é um facebook ou netflix. Nosso dia-a-dia é recheado de pequenos e médios projetos, onde talvez metade dos “grandes modelos de projetos” não se encaixam.
Porém isso não é desculpa para a não adoção dos mesmos. DRY, SOLID, KISS, Clean Code e Object Calisthenics são algumas das chaves para se tornar um profissional maduro e de qualidade.

Entenda estude e aplique esses conhecimentos, porque quando você precisar criar um facebook, terá maturidade para tomar e decidir quais caminhos você irá tomar.

that’s all folks