Criar um sistema orientado à micro serviços, na verdade, não é tão simples. Ser algo difícil e ser algo complexo são coisas distintas.
Como comentei na parte 1, vou mostrar como pode ser fácil. Imagine que temos três (3) APIs se comunicando entre si via http em um único sistema.
Pronto, você já tem o start de um sistema baseado em micro serviços. Quando trabalhamos com micro serviços, o paradigma de desenvolvimento fica um pouco diferente, eu explico:
Atenção desviada
Nossa atenção muda de foco. Em uma API Rest padrão, focamos em padrões de projeto, código limpo, desacoplamento. Isso não é perdido de foco quando mudamos para micro serviços. Entretanto, nossa preocupação maior fica no monitoramento (ou observabilidade) de serviços e dependências.
Nossa preocupação se estende à performance e resiliência das aplicações, por exemplo.
Nem tudo são rosas
É importante comentar sobre o dia a dia de grandes sistemas. Nem tudo são rosas e serviços bem orquestrados. Na verdade, dispende-se grande esforço para manter tudo em ordem.
Nem tudo é complicado também
No final das contas o que importa é se a solução resolve o problema, seja com monólito ou com micro serviços, tanto faz.
De volta à nossa aplicação
Users API
Vamos iniciar pela API de usuários. Ela será o ponto de entrada do nosso usuário.
Nossas APIs seguirão o seguinte diagrama:
Camadas da API
Como você viu no diagrama, teremos três (3) camadas em nossas APIs (sim, todas vão seguir esse padrão). Cada camada tem sua responsabilidade, vamos a elas:
Application
Dentro da camada de application temos duas estruturas.
A estrutura de Controller vai nos fornecer os recursos da API, são eles:
| Method | Route |
|---|---|
| POST | /user |
| GET | /user |
A estrutura Factory será o ponto que acoplaremos a nossa aplicação com a camada de infraestrutura. Essa camada será o lugar onde teremos todas as junções da nossa aplicação, onde vamos conectar o nosso Controller, com nosso Service, com o Repository, etc.
Infrastructure
Essa camada de infraestrutura será onde teremos as definições de arquitetura da nossa aplicação. Isso quer dizer que, todas as dependências e auxiliares que não trabalham com as regras do negócio, ficam nessa camada.
Repository: é a estrutura responsável que cria uma interface de comunicação entre nossa aplicação e a base de dados.
Data: é a estrutura responsável por buscar dados de outros lugares que não estão na base de dados. Por exemplo, consumir as outras APIs.
Adapter: é a estrutura que vai adaptar e validar os dados de entrada e saída da nossa API com o Controller.
Error: é a estrutura que modela diferentes erros baseados no comportamento da aplicação e da regra definida.
Service: é a estrutura que mescla outras estruturas com o domínio, quase assemelha-se à Factory na camada de Application
Domain
Essa é nossa camada de domínio, onde não devemos nos preocupar se vamos utilizar um ORM, filas, Frameworks ou qualquer outra dependência.
Essa camada é responsável pela regra de negócio da nossa aplicação. Isso significa que, nos preocupamos unicamente com a lógica do negócio.
Acompanhe o vídeo
Em breve
Top comments (0)