DEV Community: Leonardo Melo Santos

Usando o Nginx como API gateway no Linux

Leonardo Melo Santos — Tue, 29 Apr 2025 21:52:16 +0000

Está precisando usar o Nginx como ferramenta de API Gateway e não sabe o passo a passo para testar este cenário?

Este artigo tem o objetivo de compartilhar um passo a passo, onde você poderá instalar o Nginx no seu Linux e simular API Gateway:

Seguem os passos:

1) Instale as dependências necessárias

Antes de compilar o Nginx, você precisará instalar algumas ferramentas e bibliotecas. Para isso, execute os dois comandos abaixo:

sudo apt update

sudo apt install -y build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev wget

2) Baixe o código-fonte do Nginx

Acesse ao endereço https://nginx.org/en/download.html e baixe a versão mais estável do NGINX. Em seguida, descompacte o arquivo baixado.

3) Compile o Nginx

Para compilar o Nginx, execute os três comandos abaixo:

Configure o processo de compilação:
./configure --sbin-path=/usr/local/nginx/nginx --conf-path=/usr/local/nginx/nginx.conf --pid-path=/usr/local/nginx/nginx.pid

Compile o código-fonte:
make

Instale o Nginx:
sudo make install

4) Levante suas aplicações que serão usadas no Gateway

No exemplo deste cenário, foram levantadas duas aplicações:

5) Configue da forma como deseja

Edite o arquivo "/usr/local/nginx/nginx.conf". No exemplo abaixo foram configurados:

Porta do Nginx é a 8081, portanto será digitado no navegador o endereço "http://localhost:8081"
Dois endpoints "myapp1" e "myapp2", em que cada um deles será endereçado para aplicações/endereços diferentes

6) Inicie o Nginx

sudo /usr/local/nginx/nginx

Obs.: Quando quiser parar o Nginx, execute o comando abaixo:

sudo kill -QUIT $(cat /usr/local/nginx/nginx.pid)

Internal Developer Platform (IDP)

Leonardo Melo Santos — Thu, 24 Apr 2025 11:50:41 +0000

Já pensou em usar alguma ferramenta que pudesse ajudar na produtividade do seu time, centralizando templates, padronizações e documentações? Então chegou a hora de pensar em implantar uma ferramenta de IDP.

Em linhas gerais: Uma IDP é um conjunto de ferramentas, práticas e serviços mantidos por uma equipe de engenharia de plataforma para abstrair complexidades e aumentar a produtividade dos times de desenvolvimento. É como criar uma "plataforma como produto", mas para os desenvolvedores internos da empresa.

Essas plataformas geralmente incluem:

Catálogo de aplicações (boilerplates, templates)
Self-service para provisionamento de ambientes
Pipelines de CI/CD padronizados
Observabilidade e monitoramento integrados
Gestão de permissões e segurança
Documentação centralizada

Exemplos de Ferramentas e Plataformas que ajudam a construir uma IDP:

Backstage (by Spotify) – Um portal de desenvolvedor open-source que serve como front-end da sua IDP.
Port – Plataforma para criar portais de desenvolvimento self-service.
Humanitec – Uma das soluções mais completas para criar IDPs.
Kraken (da Zup) – Focado em automação de deploys e ambientes.
Qovery, Pluto, Cortex, entre outros.

Benefícios

Redução do acoplamento entre times de plataforma e desenvolvimento
Redução de tempo para criar e operar aplicações
Aumento de segurança e governança
Padronização das boas práticas DevOps/SRE

Exemplo de uso na prática
Imagine que um dev quer criar um novo microserviço. Em vez de clonar manualmente templates e configurar CI/CD, ele entra no portal (como o Backstage), preenche um formulário com o nome do serviço e a stack desejada, e a plataforma cria tudo: repositório, pipelines, infraestrutura, monitoramento e deploy automático no ambiente desejado.

Domain Model e as entidades persistíveis

Leonardo Melo Santos — Wed, 16 Apr 2025 02:24:45 +0000

Pergunta: Quando adotou o Domain Model Pattern, ao invés da abordagem de Transaction Script Pattern, você criou em seu projeto tanto as entidades de domínio quanto as entidades correlatas de persistência? Às vezes nos perguntamos se o Domain Model Pattern traz consigo essa obrigatoriedade das entidades persistíveis.

Primeiramente, vamos clarear algumas ideias, trazendo algumas definições/premissas:

Sobre as Entidades de domínio

No Domain Model, as entidades de domínio são fundamentais. Elas representam os conceitos principais do domínio da aplicação (por exemplo: Cliente, Pedido, Produto).
Essas entidades encapsulam o estado (atributos) e o comportamento (métodos e regras de negócio relacionadas ao conceito) de forma coesa.

Sobre as Entidades persistíveis

Em um sistema bem projetado com Domain Model, as entidades de domínio podem ser persistidas, mas o foco principal delas não é a persistência, e sim o modelamento do domínio.
A persistência é geralmente tratada por meio de técnicas como mapeamento objeto-relacional (ORM) (ex.: Hibernate, JPA) ou repositórios, que fazem a ponte entre o modelo de domínio e a infraestrutura de persistência (banco de dados).

A grande questão dessa postagem é: A separação é necessária?
Nem sempre é necessário criar uma distinção explícita entre entidades de domínio e entidades persistíveis. Em muitos casos, as entidades de domínio são diretamente persistíveis, desde que a infraestrutura permita isso sem comprometer o design do domínio.

Porém, em sistemas mais complexos, pode ser útil separar os dois contextos para evitar acoplamento excessivo com detalhes de persistência. Nesse caso, você pode utilizar Data Models para transporte de dados.

Diferença em relação ao Transaction Script

No Transaction Script, as entidades geralmente são estruturas de dados simples (como tabelas ou registros), e a lógica de negócio é tratada de forma procedural em scripts ou serviços. Isso pode levar a um design mais simples, mas menos escalável e mais difícil de manter em sistemas complexos. Essa abordagem é mais direta e se concentra em scripts separados que executam operações específicas. Ele é útil em sistemas mais simples ou onde a lógica de negócios é de fácil entendimento.
No Domain Model, a lógica de negócio é distribuída entre as entidades de domínio, promovendo coesão e encapsulamento, mas exige maior planejamento e cuidado no design. Essa abordagem foca em encapsular lógica de negócios complexa em objetos orientados a dados. Ele é ideal para aplicações que têm um comportamento intricado e persistente

Conclusão
No design de Domain Model:

As entidades de domínio são indispensáveis, pois representam os conceitos e comportamentos do domínio.
A distinção entre entidades de domínio e entidades persistíveis depende da complexidade do sistema e do grau de desacoplamento desejado entre a lógica de negócio e a infraestrutura de persistência.

Vídeos no YouTube que podem ser usados como exemplos práticos:

How To Start Using Domain-Driven Design: Pushing Logic Down - https://www.youtube.com/watch?v=q74saF54w8I
Refactoring From Transaction Script to Domain-Driven Design - https://www.youtube.com/watch?v=KTSpDZNfjhU
Transaction Script vs. Domain Model, qual estratégia de design devo adotar? - https://www.youtube.com/watch?v=tcZP0DlZD9U

Quando usar e quando não usar DDD?

Leonardo Melo Santos — Mon, 31 Mar 2025 01:42:50 +0000

Apesar de muitas pessoas afirmarem utilizar DDD apenas por possuir uma arquitetura em camadas, isto não significa que realmente estejam usando o DDD. Existem algumas interpretações como DDD-Lite que seria uma aplicação utilizando alguns conceitos encontrados no DDD porém ignorando muitos outros.

Para saber se você deve ou não implementar o DDD no seu projeto, disponibilizo abaixo um DDD Score Card extraído do livro Implementing Domain Driven Design.

Se no final o somatório dos pontos for igual ou maior que 7 considere seriamente em implementar o DDD em seu projeto.

Critério 1

Pontuação: 0 pontos
Seu contexto: Se sua aplicação for completamente centrada em dados e se qualificar verdadeiramente para uma solução CRUD pura, em que cada operação é basicamente uma consulta simples de banco de dados para criar, ler, atualizar ou excluir, você não precisa do DDD. Sua equipe só precisa colocar um rosto bonito em um editor de tabelas de banco de dados. Em outras palavras, se você puder confiar no fato de que os usuários irão inserir os dados diretamente em uma tabela, atualizá-los e, às vezes, excluí-los, você nem mesmo precisará de uma interface do usuário. Isso não é realista, mas é conceitualmente relevante. Se pudesse usar uma ferramenta simples de desenvolvimento de banco de dados para criar uma solução, você não desperdiçaria o tempo e dinheiro de sua empresa no DDD.
Análise: Isso parece óbvio, mas normalmente não é fácil determinar simples versus complexo. Não é como se todas as aplicações que não são CRUD puras merecem o tempo e o esforço do uso do DDD. Assim, talvez possamos sugerir outros indicadores para nos ajudar a traçar uma linha entre o que é complexo e o que não é …

Critério 2

Pontuação: 1 ponto
Seu contexto: Se seu sistema exigir apenas 30 ou menos operações de negócio, ele provavelmente é bem simples. Isso significaria que a aplicação não teria um total de mais de 30 histórias de usuário ou fluxos de caso de uso, com cada um desses fluxos tendo apenas uma lógica mínima de negócio. Se você puder desenvolver rápida e facilmente esse tipo de aplicação e não se importar com a falta de poder e controle em relação à complexidade e alteração, o sistema provavelmente não precisará usar o DDD.1
Análise: Para ser claro, estou falando de 25 a 30 únicos métodos de negócio, não de 25 a 30 interfaces de serviço completas, cada uma com vários métodos. O último pode ser complexo.

Critério 3

Pontuação: 2 pontos
Seu contexto: Assim, digamos que, em algum lugar no intervalo entre 30 e 40 histórias de usuário ou fluxos de caso de uso, a complexidade poderia ser pior. Seu sistema pode estar entrando no território do DDD.
Análise: O risco é do comprador: Bem frequentemente a complexidade não é reconhecida rapidamente. Nós, desenvolvedores de software, somos realmente muito bons para subestimar a complexidade e o nível de esforços. Só porque talvez queiramos codificar uma aplicação em N camadas com diversos Patterns não significa que devemos. No longo prazo, essas aplicações poderiam prejudicar mais do que ajudar.

Critério 4

Pontuação: 3 pontos
Seu contexto: Mesmo que a aplicação não seja complexa agora, a complexidade dela aumentará? Você só pode saber isso ao certo depois que os usuários reais começam a trabalhar com ela, mas há um passo na coluna "Pensamentos de suporte" que pode ajudar a revelar a situação real. Tenha cuidado aqui. Se houver absolutamente qualquer indício de que a aplicação tem complexidade mesmo moderada - este é um bom momento para ser paranoico, isso pode ser uma indicação suficiente de que ela na verdade será mais do que moderadamente complexa. Incline-se em direção ao DDD.
Análise: Aqui vale a pena analisar os cenários de uso mais complexos com especialistas em domínio e ver aonde eles levam.Os especialistas em domínio: #1 Já estão solicitando recursos mais complexos? Se sim, isso provavelmente é uma indicação de que a aplicação já é ou em breve se tornará excessivamente complexa para usar uma abordagem CRUD.#2 Estão entediados com os recursos ao ponto em que dificilmente vale a pena discuti-los? Provavelmente não é complexa.

Critério 5

Pontuação: 4 pontos
Seu contexto: Os recursos da aplicação serão alterados com frequência ao longo de alguns anos, e você não pode antecipar que as alterações serão simples.
Análise: O DDD pode ajudá-lo a gerenciar a complexidade da refatoração de seu modelo ao longo do tempo.

Critério 6 e último

Pontos: 5 pontos
Seu contexto: Você não entende o Domínio porque ele é novo. Na medida em que você e sua equipe sabem, ninguém fez isso antes. Isso provavelmente significa que ele é complexo ou, pelo menos, merece a devida diligência com análise analítica para determinar o nível de complexidade.
Análise: Você precisará trabalhar com Domain Experts e testar os modelos para fazer a coisa certa. Você certamente também pontuou em um ou mais dos critérios anteriores, portanto, use o DDD.

Ao finalizar este exercício você terá mais clareza para determinar se o DDD é viável ou não para o seu projeto. Lembre-se de tomar as decisões com foco na simplicidade, entrega e manutenção. Muitas vezes sofremos da vontade incontrolável de implementar todos os conceitos de nossos estudos, porém estamos colocando em risco o dinheiro da empresa e nossa própria carreira.