arquitetura

Camadas e componentes do padrão arquitetural Porto

O padrão arquitetural Porto possui algumas camadas para tratar cada parte da aplicação. Nesse post vamos conhecer um pouco mais sobre cada uma dessas camadas e também sobre os componentes que podem compor a camada de containers.

Caso ainda não conheça o padrão arquitetural Porto, vale a leitura do artigo onde explicamos: O que é o padrão Porto e como ele funciona.
PHP - Orientação a Objetos - Parte 1
Curso de PHP - Orientação a Objetos - Parte 1
CONHEÇA O CURSO

Camadas do padrão Porto

O padrão arquitetural Porto é composto por 2 camadas principais Ship (navio) e Containers. Conforme ilustra o diagrama abaixo:

diagrama que mostra as 3 camadas do padrão arquitetural porto

Existe também uma terceira camada mais conceitual chamada Sea (oceano), que podemos considerar como sendo os recursos de baixo nível que usamos na aplicação, como frameworks e bibliotecas, conforme mostrado acima.

Camada Ship

A camada Ship (navio) é a camada intermediária da nossa aplicação. Ela faz a ligação entre o código de baixo nível da camada Sea (oceano) e a camada de alto nível Containers.

Na parte de interação com o baixo nível que são os frameworks, bibliotecas e outras APIs de baixo nível da linguagem. A camada de Ship possui recursos, como bootstrap necessário para a aplicação, arquivos de configuração, registro de serviços e outros detalhes específicos.

Ela abriga também classes genéricas que são usadas dentro dos containers, como exceções, middlewares, classes de integração com serviços específicos, configurações compartilhadas e outros.

A camada de Ship ainda conta com classes de base. Essas classes podem ser estendidas dentro da camada Containers e permitem compartilhar código entre os diversos containers da aplicação.

Camada de containers

A camada de containers possui o código de alto nível da aplicação. Ela interage com a camada de nível intermediário (Ship).

Ela é responsável pela implementação da regra de negócio da aplicação. A ideia é que cada container contenha uma parte da regra de negócio. Ele deve receber a requisição e responder de acordo com cada UI (User Interface), que pode ser uma API, aplicação clássica web ou outra interface.

O ideal é que cada container esteja ligado a somente uma entidade/model da aplicação, mas nada impede que ele possua mais de um, porém quanto maior a quantidade de models, maior a complexidade do container, algo que o padrão estrutural tenta ao máximo evitar. Quanto mais simples os containers, maior a possibilidade de reutilizá-lo.

Componentes dos containers no padrão arquitetural Porto

Os containers são formados por componentes, cada um com sua responsabilidade. Eles podem ser componentes obrigatórios e opcionais.

O diagrama abaixo mostra como os componentes interagem dentro de um container:

Componentes da camada de containers da parquitetura porto

Os componentes pontilhados são opcionais enquanto os com linha contínua são obrigatórios. Note que temos os mesmos componentes do padrão MVC, veremos abaixo a responsabilidade deles no Porto.

Responsabilidade dos componentes no padrão arquitetural porto

Responsabilidade dos principais componentes:

  • Route – É o componente responsável por definir para cada caminho acessado qual será o controller responsável;
  • Controller – Recebe os dados da requisição, realiza a validação e autorização (em classe separada), envia para processamento em uma action e devolve a resposta apropriada;
  • Request – É o componente que obtém os dados de input da requisição. Pode também validar os dados e fazer autorização a partir deles. Deve sempre ser chamada a partir do controller;
  • Action – É responsável por receber os dados do controller, processar e devolver a ele. Ela está diretamente ligada a uma regra de negócio específica, se estivermos usando diagrama de caso de uso, podemos dizer que uma action é responsável por um caso de uso específico;
  • Task – Componente onde podemos colocar pequenas regras de negócio e que serão chamadas por diferentes actions do mesmo container ou de outros para evitar duplicidade;
  • Model – Usado para representar a estrutura no banco de dados. Ele não deve conter regras de negócio, apenas elementos referente ao mapeamento das tabelas e relacionamentos do banco de dados;
  • View – Elemento usado para separar o HTML da lógica da aplicação. Usada somente para UI (User Interface) web;
  • Transformers – Responsável por preparar os dados de saída quando trabalhamos com retornos para API. Sua principal vantagem é desacoplar o modo como os dados são retornados pelos modelos, permitindo a API retorna-los conforme sua necessidade;
  • Exceptions – Classes de exceções personalizadas, usadas para especificar as exceções que acontecem dentro do container;
  • Sub-Actions – Possui basicamente a mesma função das actions, porém é usada para eliminar duplicação de código. Ao invés repetir o mesmo código em duas Actions, usamos uma sub-action.

Existe também os componentes opcionais que podem ser usados conforme a necessidade do projeto.

Estrutura de pastas de container no padrão Porto

Abaixo é possível ver a estrutura de pastas de um container usando os principais componentes que conhecemos:

Container
    ├── Actions
    ├── Tasks
    ├── Models
    ├── Exceptions
    ├── Tests
    │   ├── Unit
    │   └── Traits
    └── UI
        ├── API
        │   ├── Routes
        │   ├── Controllers
        │   ├── Requests
        │   ├── Transformers
        │   └── Tests
        │       └── Functional
        ├── WEB
        │   ├── Routes
        │   ├── Controllers
        │   ├── Requests
        │   ├── Views
        │   └── Tests
        │       └── Acceptance
        └── CLI
            ├── Routes
            ├── Commands
            └── Tests
                └── Functional

Seções de containers

Os containers podem ser agrupados em seções. O principal objetivo delas é separar os containers de acordo com o contexto.

Cada seção de containers pode representar uma parte do seu sistema, o arquiteto tem a liberdade de escolher como criar as sessões e quais containers estarão dentro dela de acordo com sua aplicação.

Desenvolvedor Django Full-Stack
Formação: Desenvolvedor Django Full-Stack
Aprenda nesta formação como desenvolver aplicações complexas utilizando o Django, principal framework para desenvolvimento web de todo o ecossistema Python. Para isso, você verá desde os conceitos mais básicos, até conceitos mais avançados.
CONHEÇA A FORMAÇÃO

Considerações finais

O padrão arquitetural Porto faz uso de vários conceitos que já são utilizados normalmente em aplicações back-end, o que facilita aos desenvolvedores compreenderem o que cada componente faz e também garante algumas características já comprovadas ao utilizar esses conceitos.

Você pode ler a documentação completa sobre o padrão Porto no seu repositório do Github.

Conheça o padrão arquitetural Porto para aplicações back-end

Nesse post vamos conhecer o padrão arquitetural Porto. Voltado principalmente para aplicações back-end, ele usa conceitos de diversos outros padrões para definir um padrão modular, com baixo acoplamento e altamente testável.

Python - Orientação a objetos
Curso de Python - Orientação a objetos
CONHEÇA O CURSO

O Que é Porto?

O Porto é um padrão arquitetural criado por Mahmoud Zalt. Seu principal objetivo é ajudar os desenvolvedores a criarem aplicações de médio e grande porte de forma manutenível e reutilizável.

Ele utiliza conceito de outros padrões já largamente usados e conhecidos, como DDD (Domain Driven Design), Modular, Micro Kernel, MVC (Model View Controller), Layered e ADR (Action Domain Responder). O Porto também se utiliza de uma série de princípios, como SOLID, programação orientada a objetos, LIFT, DRY (Don’t repeat yourself), CoC (Convention over configuration), GRASP (General Responsibility Assignment Software Patterns), generalização, alta coesão e baixo acoplamento.

Ele foi criado pensando nos principais problemas do desenvolvimento web back-end, porém pode ser utilizado também em outros tipos de aplicação. Uma das suas principais vantagens é que ele permite a criação de aplicações monolíticas de forma organizada e caso necessário ainda facilita a divisão em micro serviços, graças ao modo como é estruturado.

Como funciona o padrão arquitetural Porto?

O padrão arquitetural Porto pode ser usado independente de tecnologia e está baseado em duas camadas principais, Ship (navio) e Containers. Ele ainda considera uma terceira camada que chama Sea (oceano) que basicamente consiste no código de baixo nível, como, frameworks e bibliotecas que nossa aplicação interage.

Abaixo podemos ver uma imagem ilustrando as camadas:

imagem que mostra as camadas do padrão arquitetural Porto (ship, containers e sea)

A camada Ship (navio) é a camada intermediária da nossa aplicação. Ela faz a ligação entre o código de baixo nível da camada Sea (oceano) e a camada de alto nível Containers. Sua responsabilidade principal é interagir com recursos do framework e bibliotecas, além de possuir elementos base para a camada de containers.

A camada de containers possui o código de alto nível da aplicação. Ela interage com a camada de nível intermediário (Ship). Sua responsabilidade é cuidar das regras de negócio do projeto.

O problema das múltiplas interfaces

O desenvolvimento de aplicações que possuem múltiplas UI User Interface (interface de usuário) é uma realidade no mercado. Na maioria dos casos, as aplicações são desenvolvidas para no mínimo duas UI. A interface web e a interface para dispositivos móveis, através de aplicativos específicos para Android e IOS.

Baseado nesse cenário as aplicações back-end precisam servir a diferentes aplicações. Isso pode ser um grande problema, uma vez que por mais que as interfaces de usuário tenham na maioria dos casos os mesmos requisitos, existem situações onde os requisitos são diferentes. Essa situação pode causar um gargalo no projeto, já que temos várias equipes de aplicações front-end solicitando desenvolvimento de novos recursos.

O problema descrito acima, pode ser tratado de diversos modos, como utilizando o padrão back-ends for front-ends, onde temos um back-end para cada interface de usuário ou até mesmo usando diferentes API gateway quando estamos usando micro-serviços.

O padrão arquitetural Porto como uma alternativa

As abordagens levantadas acima são interessantes, porém elas trazem um custo a mais para o projeto, manter diferentes back-ends para diferentes front-ends pode ser muito custoso. E a abordagem de micro-serviços não se aplica a qualquer tipo de projeto, uma vez que existe um ganho significante de complexidade de controle dos serviços em relação a uma aplicação monolítica.

O padrão arquitetural Porto trás características que nos ajuda no cenário descrito acima. Ele é estruturado de forma a permitir que a aplicação back-end possa responder a diferentes interfaces de usuário usando as mesmas regras de negócio. Ele também permite que a aplicação seja estruturada inicialmente como monolito que pode ser migrado, caso necessário, com o crescimento da aplicação para o modelo de micro-serviços.

Por que conhecer o padrão estrutural Porto?

O padrão arquitetural Porto é importante como uma nova proposta para o mercado, uma vez que ele tenta atacar gaps que outros padrões conhecidos possuem.

O modo como ele foi estruturado, garante uma série de atributos de qualidade ao projeto. Elementos como modularidade dão ao padrão uma característica bem interessante, a possibilidade de transformar uma aplicação monolítica em micro serviços, algo extremamente difícil nos padrões amplamente utilizados no mercado

Devido a sua filosofia de responsabilidade única, classes pequenas e padrões bem definidos de entradas e saída. O padrão Porto permite a criação de aplicações altamente testáveis e manuteníveis.

Outro aspecto muito interessante, é o fato da regra de negócio da aplicação estar desacoplado da UI (User Interface). Desse modo é possível que uma aplicação utilize a mesma lógica para responder diferentes tipos de aplicações. Por exemplo, uma API, uma aplicação web e uma aplicação console.

Padrão arquitetural Porto na comunidade

A tendência é de acordo com que mais pessoas conheçam o padrão, ele ganhe espaço no mercado, uma vez que é possível implementá-lo na maioria das tecnologias usadas para desenvolvimento de aplicações back-end.

A comunidade de desenvolvimento de software está sempre aberta a novos padrões como é o caso do Porto, porém como é algo normal em tecnologia, é necessário um tempo de maturação até que as empresas comecem adotar em produtos reais.

Desenvolvedor Laravel Full-Stack
Formação: Desenvolvedor Laravel Full-Stack
Nesta formação você aprenderá desenvolver aplicações PHP usando o framework Laravel com maestria. Ao final desta formação, você terá condições de trabalhar em grandes aplicações web ou APIs integradas com diversos serviços, tudo isso utilizando as melhores práticas do mercado.
CONHEÇA A FORMAÇÃO

Considerações finais

Atualmente o Porto ainda é uma padrão arquitetural que está mais presente na comunidade PHP, mais especificamente na comunidade Laravel, uma vez que seu criador faz parte dessa comunidade e também mantém uma implementação do padrão sobre o Laravel chamado Apiato.

Apesar de estruturado sobre diversos outros padrões e componentes conhecidos do mercado, o Porto ainda não foi implementado largamente. Isso faz com que não seja possível comprovar de maneira prática seus atributos de qualidade.

O que são microsserviços?

O termo “microsserviços” tem sido muito utilizado nos últimos anos. Confira neste artigo o que é um microsserviço e quando utilizá-lo.

Afinal, o que vem a ser os microsserviços?

Microsserviços são uma abordagem de arquitetura para a criação de aplicações, onde cada pedaço dessa aplicação é desenvolvido e disponibilizado de forma independente. Cada processo da aplicação é executado como um serviço.

Quando falamos em microsserviços, estamos nos referindo a uma funcionalidade que pode ser dividida em partes menores. Desse modo, essas pequenas partes se comunicam por meio de uma interface bem definida usando APIs. Em outras palavras, como são executados de forma independente, cada serviço pode ser atualizado e implantado para atender às demandas de uma aplicação.

Uma arquitetura de microsserviços é um estilo moderno de arquitetura para web services, o que nos remete a outra arquitetura: a SOA. A SOA é uma alternativa à abordagem tradicional de construção de aplicações autossuficientes, as quais chamamos de monolíticos.

Se forem construídos corretamente, os serviços independentes não afetarão uns aos outros, ou seja: se um deles falhar, o restante da aplicação permanecerá em funcionamento, ao contrário do modelo monolítico.

O que são aplicações monolíticas e quais os problemas?

Ao contrário dos microsserviços, as aplicações monolíticas tem todas suas funcionalidades em um único processo, fazendo com que tenha um grande conjunto de funcionalidades em uma única estrutura, gerando alto acoplamento e indisponibilidade de toda a aplicação caso haja alterações ou implantação, mesmo que haja apenas um único ponto de falha.

Ainda assim, ele é interessante para aplicações pequenas, mas caso você esteja trabalhando com uma aplicação um pouco maior, alguns problemas podem surgir.

Quais são os benefícios da arquitetura de microsserviços?

A utilização de microsserviços pode trazer muita produtividade, pois você pode desenvolver vários microsserviços ao mesmo tempo, com diversos desenvolvedores trabalhando de forma simultânea na mesma aplicação com abordagens diferentes (como tecnologias envolvidas). Nesse sentido, temos nossas equipes bem focadas em suas tarefas, resultando em mais produtividade em menos tempo e um trabalho mais eficiente.

Flask - Fundamentos
Curso de Flask - Fundamentos
CONHEÇA O CURSO

Vantagens e desvantagens de se utilizar microsserviços

Vantagens
  • agilidade: com os deploys e testes independentes, temos uma maior agilidade no desenvolvimento e na implantação;
  • baixo acoplamento: com as aplicações são independentes, elas não possuem um acoplamento forte entre si. Isso facilita processos de manutenção, implantação e monitoramento;
  • escalabilidade flexível: cada serviço e funcionalidade pode ser escalado de maneira mais adequada e granular. Com isso, é possível obter até mesmo economia na manutenção da infraestrutura, pois o hardware pode ser escalado de maneira mais efetiva;
  • flexibilidade para implantação de tecnologias heterogêneas: como não existe acoplamento explícito e cada serviço é independente, podemos ter diferentes serviços escritos em diferentes tecnologias comunicando-se entre si. Isso permite utilizar linguagens mais adequadas para diferentes situações.
Desvantagens:
  • Complexidade na implementação e operação de sistemas distribuídos: sistemas distribuídos trazem complexidades adicionais, como monitoramento, consistência e distribuição de transações, pulverização de fontes de dados etc.;
  • Testes: testar uma aplicação com muitas dependências de serviços pode ser desafiador.

Quando deve-se considerar utilizar essa abordagem?

É preciso entender quando e como usar corretamente uma arquitetura orientada a microserviços. Pontos como complexidade do negócio, tamanho da equipe e distribuição das atividades são pontos relevantes a serem considerados. Caso contrário, a chance da adoção de uma arquitetura orientada a microserviços fracassar cresce consideravelmente.

Por isso, alguns casos que devem ser levado em conta ao utilizar a abordagem de microsserviços é em aplicações grandes e complexas. Essas aplicações geralmente precisam de uma alta taxa de velocidade de liberação, além de precisarem ser altamente escaláveis e disponíveis.

Considerações finais…

Os microsserviços são parte importante da estratégia de desenvolvimento de projetos distribuídos e altamente escaláveis. A utilização de microsserviços facilitam a escalabilidade e na agilidade do desenvolvimento, acelerando o tempo de introdução de novos recursos.

O que é MVC?

Em meio ao desenvolvimento de software, você pode ter visto em algum momento a sigla “MVC”. Confira neste artigo o que vem a ser o MVC – ou Model-View-Controller.

Afinal, o que é MVC?

O MVC é um padrão de arquitetura de software. O MVC sugere uma maneira para você pensar na divisão de responsabilidades, principalmente dentro de um software web.

O princípio básico do MVC é a divisão da aplicação em três camadas: a camada de interação do usuário (view), a camada de manipulação dos dados (model) e a camada de controle (controller).

Com o MVC, é possível separar o código relativo à interface do usuário das regras de negócio, o que sem dúvida traz muitas vantagens que veremos mais à frente.

Quais os papéis de cada camada?

Quando falamos sobre o MVC, cada uma das camadas apresenta geralmente as seguintes responsabilidades:

Model
A responsabilidade dos models é representar o negócio. Também é responsável pelo acesso e manipulação dos dados na sua aplicação.

View
A view é responsável pela interface que será apresentada, mostrando as informações do model para o usuário.

Controller
É a camada de controle, responsável por ligar o model e a view, fazendo com que os models possam ser repassados para as views e vice-versa.

Vamos a um exemplo…

Vamos utilizar o exemplo de uma página web, onde o usuário pode realizar o cadastro de clientes.
Neste caso, provavelmente você teria uma classe chamada cliente.php que contém as informações do cliente que você deseja guardar (como nome, endereço, cidade, etc.). Essa classe seria o seu model.

Aqui, ainda poderíamos acoplar aspectos de manipulação de bancos de dados, concentrando nesta estrutura os métodos para inserir, alterar, excluir e listar os clientes a partir de uma tabela em um banco de dados.

A página HTML seria nossa view, que mostraria, por exemplo, a lista de usuários cadastrados ou mesmo o próprio formulário para cadastro de novos usuários.

O controller faz o meio de campo entre o model e a view. Ele é necessário porque as estruturas presentes com view não deveriam acessar diretamente os models, já que isso poderia criar um acoplamento entre as estruturas de apresentação e definição de negócio: é necessária uma estrutura intermediária para fazer essa ligação.

E aqui entra o controller, que age como uma ponte entre os dois. Você pode ter uma classe dentro do seu projeto PHP para fazer o papel de um controller, realizando a ligação entre models e views.

O MVC e sua importância

Não dá para falar do MVC sem citar a importância que ele traz em meio ao desenvolvimento de software.

Uma dessas vantagens é que ele nos ajuda a deixar o código mais manutenível, ou seja, mais fácil de fazer manutenção, já que temos as responsabilidades devidamente separadas. Isso também traz uma facilidade na compreensão do código, além da sua reutilização.

Além disso, você tem um código mais testável, pois ele é mais granular: se você tem uma aplicação onde, por exemplo, na página de listagem de usuários, o nome do usuário está sendo cortado ou não está sendo exibido da maneira correta, é muito mais fácil você fazer um teste que atinja somente as estruturas de views.

Aqui, podemos ver claramente que você tem um problema de apresentação: os models não são responsáveis por aspectos de apresentação, assim como os controllers também não são… Veja que é até mais fácil de identificar que o problema está na view. Por isso, você consegue corrigir somente a view e testá-la de maneira isolada.

Um segundo exemplo seria se você tivesse um problema de validação ou uma informação de um campo que o usuário está preenchendo na view e não está chegando no banco de dados: não é a view que envia coisas para o banco de dados, assim como também não é o model que é responsável por esse papel (aliás, o model pode até enviar coisas para o banco de dados, mas essas informações são repassadas por outras estruturas anteriores).

Então, podemos chegar à conclusão de que o problema é no controller. Sendo assim, você consegue trabalhar somente no controller, sabendo que as alterações provavelmente não irão impactar nas views e nos models. Além disso, você conseguirá realizar testes de uma maneira muito mais rápida e eficiente.

Considerações finais…

Por conta dessas facilidades que o MVC oferece, ele passou a ser adotado por diversos frameworks. Além disso, o MVC pode ser utilizado em diversos tipos de projetos, se tornando muito popular no desenvolvimento web, embora você também pode criar uma aplicação MVC para outras plataformas, como desktop ou mobile.

Caso você tenha dúvida se pode utilizar o MVC em qualquer linguagem de programação, a resposta é sim: isso porque o MVC não é um conceito de linguagem de programação, e sim um conceito de arquitetura. Você não tem uma linguagem que suporte isso ou não: basta você seguir os princípios da arquitetura, que estão mais focados em separar as responsabilidades das coisas do que na tecnologia em si.

É importante que todo desenvolvedor tenha conhecimento sobre o MVC, pois ele é amplamente utilizado e difundido pelo mercado. Também é interessante conhecer outros patterns baseados no MVC e que são utilizados com frequência no mercado, como o MVVM e o MVP.

© 2004 - 2019 TreinaWeb Tecnologia LTDA - CNPJ: 06.156.637/0001-58 Av. Paulista, 1765, Conj 71 e 72 - Bela Vista - São Paulo - SP - 01311-200