Por que 90% dos Programadores Júnior não conseguem emprego? (E como não ser um deles)

Se você passou os últimos meses estudando, terminou cursos, enviou dezenas de currículos e não obteve retorno, ou pior, travou na hora da entrevista técnica, saiba que você não está sozinho. Existe uma crença de que o mercado de tecnologia está completamente fechado para iniciantes, mas a realidade é diferente: vagas existem, o que falta são candidatos com o nível mínimo de preparo prático.

O mercado saturou de pessoas que assistem a centenas de horas de vídeo, mas nunca escreveram uma linha de código do zero. Para ter sucesso, você precisa entender que as empresas não querem saber quantos certificados você tem, mas sim o que você é capaz de construir com o que aprendeu.

O Grande Insight: Seu Código é o Seu Currículo

Em profissões como arquitetura ou design, os profissionais apresentam portfólios com seus projetos e layouts. Na programação, o seu portfólio é o seu código, e o lugar dele é no GitHub. Enviar um currículo sem o link do seu portfólio de código é o mesmo que tentar uma vaga de design sem mostrar nenhuma arte.

O link do seu perfil deve estar no topo do seu currículo, se possível na primeira linha e em negrito. É a primeira coisa que um recrutador técnico vai olhar.

Os 6 Motivos que Impedem a Contratação de um Júnior

1. Falta de Base Prática

Muitos profissionais iniciantes dominam frameworks modernos, mas falham miseravelmente em conceitos fundamentais. Se você sabe usar ferramentas avançadas, mas não entende como funciona um loop ou uma estrutura de dados, você cairá no primeiro teste técnico.

2. Projetos Inacabados e Clones de Tutoriais

Ter um perfil cheio de repositórios com apenas um commit demonstra que você começa as coisas e nunca as termina. Vale muito mais ter um único projeto simples, mas que esteja completamente funcional e resolvendo um problema real, do que dez projetos inacabados ou copiados de tutoriais.

3. Não Saber Explicar o Próprio Código

Com a facilidade das ferramentas de Inteligência Artificial, ficou simples gerar códigos complexos. No entanto, os recrutadores identificam isso facilmente na entrevista ao pedir para você explicar o funcionamento de um trecho específico. Se você não conseguir explicar com calma o que escreveu, a empresa saberá que a IA fez o trabalho por você.

4. Ignorar o Banco de Dados (SQL)

Muitos cursos focam excessivamente na linguagem de programação e ignoram os bancos de dados. Saber o básico de SQL é obrigatório para quase totalidade das vagas de júnior. Você não precisa ser um especialista em infraestrutura de dados, mas precisa dominar comandos fundamentais como:

• SELECT para consultar informações
• INSERT para inserir dados
• UPDATE para atualizar registros
• DELETE para remover dados
• Joins para relacionar tabelas

5. Currículos Desonestos ou Humildade Excessiva

Dizer que tem nível avançado em uma tecnologia sem dominar nem a lógica básica vai te desclassificar na primeira entrevista técnica. Por outro lado, o excesso de humildade e a insegurança extrema também afastam os recrutadores. A empresa já sabe que você é júnior; o que ela busca é alguém com fundamentos firmes e capacidade de aprender.

6. Invisibilidade no Mercado

Para ser contratado, você precisa existir na internet de forma profissional. Muitas vagas em empresas pequenas e médias ocorrem por indicação e visibilidade. Participar de comunidades, fóruns e interagir no LinkedIn ajuda a construir sua presença.

O Portfólio Ideal por Área de Atuação

Para se destacar, os projetos no seu portfólio precisam falar a mesma língua da vaga para a qual você está se candidatando:

Sistemas Corporativos (ERP)

É um dos mercados com maior volume de vagas. Para essa área, seu portfólio precisa conter um CRUD completo (cadastro, tela de interface, validações e conexão com o banco de dados). Criar uma aplicação simples de contas a pagar e receber, com um recurso que exporte relatórios para PDF ou Excel, aumentará drasticamente suas chances de contratação.

Desenvolvimento Web

É a área mais concorrida. Mostre que você consegue entregar uma aplicação do início ao fim construindo um sistema que integre front-end, back-end (uma API própria) e banco de dados. Implemente recursos reais como autenticação com login e senha protegidos por hash. Além disso, faça o deploy do projeto em servidores gratuitos para que o recrutador possa testar o sistema funcionando na prática.

Desenvolvimento Mobile

Uma área com escassez de profissionais qualificados. Crie um aplicativo funcional e, no arquivo explicativo do repositório, insira imagens ou um vídeo demonstrando o funcionamento dele. É importante demonstrar que o aplicativo consome dados de uma API externa (como uma busca de CEP) e armazena informações localmente no dispositivo.

Plano de Ação Prático

Se você deseja mudar o rumo das suas candidaturas, siga estes passos:

• Faça uma limpeza no seu perfil de código, removendo exercícios soltos ou cópias de cursos.
• Escolha uma aplicação simples e desenvolva ela inteiramente por conta própria, do começo ao fim.
• Escreva uma boa documentação explicando o que o projeto faz, as tecnologias utilizadas e como executá-lo.
• Estude e domine os comandos básicos de SQL.
• Pare de acumular novos cursos e comece a construir coisas reais com o conhecimento que você já possui.

O mercado de tecnologia não está fechado para bons profissionais, mas está saturado para quem acredita que apenas assistir a aulas é o mesmo que aprender a programar. Quem entra no mercado é quem tem código real para mostrar.

Feito!

Instalando o Ollama + Open WebUI com segurança do jeito certo

Guia passo a passo para implantar Ollama + Open WebUI em uma VPS Linux com Docker, isolamento de rede e HTTPS.

Visão Geral

Este guia replica a instalação segura do Ollama com o Open WebUI em uma VPS limpa (Ubuntu 22.04 ou 24.04), utilizando Docker e isolamento de rede. Nesta configuração, o Ollama ficará restrito a uma rede interna fechada, nenhuma porta sua é exposta ao host. O Open WebUI será o único ponto de entrada, protegido por autenticação (login/senha) e, opcionalmente, por HTTPS.

Passo 1: Atualizar o Sistema e Instalar o Docker

Acesse sua VPS via SSH e instale o Docker e o Docker Compose:

Atualizar a lista de pacotes do sistema

sudo apt update && sudo apt upgrade -y

Instalar dependências necessárias

sudo apt install -y curl apt-transport-https ca-certificates software-properties-common

Adicionar a chave GPG oficial do Docker

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Adicionar o repositório do Docker

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update

Instalar o Docker e o Docker Compose

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Iniciar e habilitar o serviço do Docker

sudo systemctl start docker
sudo systemctl enable docker

Nota: O pacote docker-compose-plugin fornece o comando docker compose (sem hífen). Certifique-se de usá-lo como docker compose nos passos seguintes.

Passo 2: Criar a Estrutura de Diretórios e o docker-compose.yml

Para garantir a segurança, utilizaremos o Docker Compose para criar uma rede isolada. A porta 11434 do Ollama não será mapeada para a VPS (usamos apenas expose, omitindo o parâmetro ports), impedindo qualquer acesso externo a ela.

1. Crie uma pasta para o projeto e entre nela:

mkdir -p ~/ollama-webui && cd ~/ollama-webui

2. Crie o arquivo docker-compose.yml:

nano docker-compose.yml

3. Cole o conteúdo abaixo:

version: '3.8'

networks:
  ai-network:
    driver: bridge

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
# SEGURANÇA: porta 11434 NÃO exposta no host.
# Acessível apenas internamente para containers na rede 'ai-network'.
    expose:
      - "11434"
    restart: unless-stopped
    networks:
      - ai-network

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    volumes:
      - open_webui_data:/app/backend/data
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_AUTH=true
    restart: unless-stopped
    depends_on:
      - ollama
    networks:
      - ai-network

volumes:
  ollama_data:
  open_webui_data:

Atenção: O mapeamento 127.0.0.1:8080:8080 faz o Open WebUI responder apenas localmente na VPS. Nenhuma porta fica acessível pela rede externa sem um proxy reverso (Nginx). Isso é intencional, o Nginx com HTTPS será configurado nos passos seguintes.

Pressione Ctrl+O, Enter para salvar e Ctrl+X para sair.

Passo 3: Inicializar os Containers

sudo docker compose up -d

Verifique se os containers estão rodando:

sudo docker ps

Passo 4: Garantir a Segurança no Firewall da VPS

Se você utiliza o UFW (firewall padrão do Ubuntu):

Permitir SSH (essencial para não perder o acesso à VPS)

sudo ufw allow ssh

Permitir apenas a porta HTTP (temporário, até configurarmos o HTTPS)

sudo ufw allow 80/tcp

Ativar o firewall

sudo ufw enable

Nota: Após configurar o HTTPS no Passo 6, remova a regra da porta 80 (ou mantenha-a, o Certbot a utiliza para renovação automática) e libere a 443.

Passo 5: Primeiro Acesso e Configuração

Abra o navegador e digite o endereço IP da sua VPS: http://seu_ip_da_vps. A tela de login do Open WebUI será exibida. Clique em Sign Up (Cadastrar).

⚠️ Muito Importante: O primeiro usuário cadastrado torna-se automaticamente o Administrador global do sistema. Guarde bem essa senha.

Baixar modelos pelo terminal (Recomendado)

Para baixar um modelo, execute o comando dentro do container do Ollama. O Open WebUI reconhecerá e listará o modelo automaticamente na interface:

sudo docker exec -it ollama ollama run llama3

Substitua llama3 pelo modelo desejado: gemma2, mistral, phi3, etc.

Por que baixar pelo terminal? Para modelos muito grandes, o download pelo terminal permite acompanhar a porcentagem real sem o risco de a aba do navegador desconectar ou expirar.

Passo 6: Adicionar SSL/HTTPS com Nginx + Certbot

Para evitar que senhas e conversas trafeguem em texto puro (HTTP), configure um domínio na sua VPS e gere um certificado digital gratuito com o Nginx e Certbot.

6.1 Instalar Nginx e Certbot

sudo apt install -y nginx certbot python3-certbot-nginx

6.2 Criar a Configuração do Nginx

Crie o arquivo de configuração para o seu domínio (substitua seu-dominio.com):

sudo nano /etc/nginx/sites-available/open-webui

Cole o conteúdo abaixo:

server {
   listen 80;
   server_name seu-dominio.com;

   client_max_body_size 100M;

 location / {
  proxy_pass http://127.0.0.1:8080;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  # WebSockets — necessário para streaming de texto em tempo real
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

  # Desativa buffer para resposta aparecer palavra por palavra
  proxy_buffering off;
  proxy_read_timeout 600s;
  }
}

6.3 Ativar o Site e Reiniciar o Nginx

Ativar o site

sudo ln -s /etc/nginx/sites-available/open-webui /etc/nginx/sites-enabled/

Remover a configuração padrão (evita conflitos)

sudo rm /etc/nginx/sites-enabled/default

Testar a sintaxe

sudo nginx -t

Reiniciar o Nginx

sudo systemctl restart nginx

6.4 Obter o Certificado SSL Gratuito

sudo certbot --nginx -d seu-dominio.com

O Certbot fará perguntas simples (como seu e-mail) e configurará o redirecionamento automático de HTTP para HTTPS.

6.5 Atualizar o Firewall

Liberar HTTPS

sudo ufw allow 443/tcp

Opcional: remover a permissão da porta 80 (mantenha se quiser renovação automática do Certbot)

sudo ufw delete allow 80/tcp

Considerações finais

Ollama e Open WebUI estão blindados dentro do servidor:

• Ollama isolado em rede interna — sem porta exposta ao host.
• Open WebUI acessível apenas via localhost:8080, protegido por autenticação.
• Nginx como proxy reverso com HTTPS (SSL), tráfego criptografado.
• Firewall configurado permitindo apenas SSH (22) e HTTPS (443).
• Modelos baixados via terminal dentro do container com segurança.

Feito!

Como escalar sistemas no mundo real

Muitos desenvolvedores acreditam que a escalabilidade horizontal se resume a criar cópias de um servidor e colocar um balanceador de carga na frente. No entanto, o desenvolvimento de sistemas resilientes exige um entendimento profundo de redes, do Modelo OSI e do comportamento da sua aplicação.
Com base no conteúdo técnico de especialistas em arquitetura de software, este artigo detalha os fundamentos essenciais para você dominar o balanceamento de carga e escalar sistemas na vida real.

1. Escalabilidade Vertical vs. Escalabilidade Horizontal

Antes de distribuir o seu sistema em várias máquinas, é preciso entender a ordem natural de evolução de uma infraestrutura.

Escalabilidade Vertical (Scale Up)

Consiste em adicionar mais recursos computacionais ao servidor existente, como mais memória RAM, maior poder de processamento (CPU) ou armazenamento. É o primeiro passo recomendado antes de qualquer alteração arquitetural.
Contudo, ela possui limites físicos óbvios, torna-se extremamente cara a partir de certo ponto e mantém um problema crítico: o SPOF (Single Point of Failure). Se essa máquina única falhar ou o data center cair, a aplicação inteira fica fora do ar.

Escalabilidade Horizontal (Scale Out)

É a estratégia de criar réplicas do servidor da sua aplicação para trabalharem em conjunto. Um Load Balancer (balanceador de carga) é posicionado na ponta para receber todas as requisições dos usuários e distribuí-las entre as réplicas. Isso remove o ponto único de falha e permite o uso de hardware mais simples e barato.

Uma dúvida comum é: se a aplicação precisa de escala por não aguentar o tráfego, por que o Load Balancer, que também é um servidor único, aguenta?
A resposta está no nível de operação. Uma aplicação web tradicional consome muito tempo iniciando frameworks, processando regras de negócio e consultando bancos de dados. O Load Balancer foi projetado exclusivamente para extrair o máximo do hardware em baixo nível, atuando apenas como um direcionador ultraveloz sem executar lógicas pesadas.

2. Camadas de Operação: Camada 4 vs. Camada 7

Os balanceadores de carga não funcionam todos da mesma forma. Eles operam em diferentes camadas do Modelo OSI, e essa escolha muda completamente o comportamento do tráfego.

Camada 4 (Layer 4 - Camada de Transporte)

Opera ao nível de protocolos raiz como TCP e UDP. Este balanceador é considerado "cego", pois não abre e não analisa o conteúdo da requisição; ele enxerga apenas o IP de origem e o IP de destino.
Por não interceptar o pacote, entrega altíssima velocidade, baixíssima latência e grande vazão de dados (throughput). É ideal para:

• Jogos online em tempo real (FPS).
• Aplicações de streaming de vídeo ou chamadas (como Google Meet), que utilizam UDP e aceitam pequenas perdas de pacotes.
• Arquiteturas de mensageria massiva baseadas em conexões persistentes de WebSockets (como o WhatsApp).

Camada 7 (Layer 7 - Camada de Aplicação)

Opera diretamente no nível do protocolo HTTP. Ao contrário da Camada 4, ele intercepta a requisição, desempacota o conteúdo e consegue ler a URL, os headers, os cookies e os tokens de autenticação (como JWT).
Embora adicione uma pequena latência pelo processamento, ele permite um roteamento contextual inteligente. É recomendado para 90% das aplicações web tradicionais, e-commerces e microsserviços, permitindo regras como:

• Se a URL contiver /pedidos, envie para o Cluster A.
• Se a URL contiver /pagamentos, envie para o Cluster B.
• Aplicação centralizada de Rate Limiting e segurança.

3. Configuração Prática no Nginx

Para tirar o conceito do papel e implementar um balanceador de carga em Camada 7, o arquivo de configuração nginx.conf pode ser estruturado de maneira simples. No exemplo abaixo, o bloco upstream backend agrupa as três instâncias da aplicação rodando localmente (nas portas 8001, 8002 e 8003). O servidor do Nginx escuta na porta 8080 e repassa o tráfego usando a diretiva proxy_pass:

4. Algoritmos de Balanceamento e Complementações no Nginx

A escolha do algoritmo correto de distribuição de carga define o sucesso da infraestrutura. Veja abaixo como complementar o bloco upstream do seu Nginx para alterar a estratégia de balanceamento:

Round Robin (Circular)

É o algoritmo padrão (default) do Nginx. Ele distribui as requisições de forma estritamente sequencial e circular. Não exige nenhuma palavra-chave adicional, bastando listar os servidores como no exemplo base:

http { 

upstream backend {

    server localhost:8001;

    server localhost:8002;

    server localhost:8003;

}
server {
     listen: 8080;
     location / {
        proxy_pass http://backend;
     } 

  } 

} 

Weighted Round Robin (Ponderado)

Utilizado quando os servidores possuem capacidades de hardware diferentes. Adiciona-se o parâmetro weight para definir a proporção de carga que cada um deve receber. No exemplo abaixo, a porta 8001 receberá três vezes mais requisições que as outras duas:

  

http { 
  
     upstream backend {

    server localhost:8001 weight=3;

    server localhost:8002;

    server localhost:8003;

    } 

  server {
     listen: 8080;
     location / {
        proxy_pass http://backend;
     } 

  } 

} 

Least Connections (Menor número de conexões)

Direciona a nova requisição sempre para o servidor que tiver menos conexões ativas no momento da chamada, sendo ideal para aplicações com processamentos pesados e demorados. Para ativá-lo, basta adicionar a diretiva least_conn; no topo do bloco:

http { 
  
upstream backend {

    least_conn;

    server localhost:8001;

    server localhost:8002;

    server localhost:8003;

}
server {
     listen: 8080;
     location / {
        proxy_pass http://backend;
     } 

  } 

} 

Outros Algoritmos Notáveis

• Least Response Time (Menor tempo de resposta): Identificado pela diretiva least_time (disponível apenas no Nginx Plus), direciona o tráfego com base na latência e saúde em tempo real do servidor.


• Sticky Round Robin (Sessões Coladas): Utiliza mecanismos como cookies ou a diretiva ip_hash; para garantir que um usuário específico seja sempre direcionado para a mesma instância. Essencial para escalar monólitos que guardam estado de sessão em memória (stateful).

Considerações finais

A arquitetura de software de alta disponibilidade é guiada por escolhas e compensações (tradeoffs). Conexões de Camada 4 mantêm o cliente preso a uma conexão TCP aberta de forma persistente, o que é inviável para navegação web comum, mas indispensável para tempo real. Por outro lado, a Camada 7 oferece inteligência de roteamento à custa de mais processamento.
Dominar esses fundamentos de rede e saber configurar o algoritmo correto para a natureza do seu tráfego é o que separa um desenvolvedor comum de um verdadeiro engenheiro de sistemas escaláveis.

Referência

https://nginx.org/en/docs/http/load_balancing.html

Feito!

O Imposto Oculto da IA: Por que usar prompts em português na ferramenta de IA custa 62% mais caro?

Se você utiliza prompt na ferramenta/agente de IA no seu dia a dia, seja programando com o Claude, gerando relatórios no ChatGPT ou criando automações com o Gemini, existe um detalhe invisível na sua conta que provavelmente está passando despercebido.

Você sabia que, para transmitir a mesmíssima informação, você pode estar gastando muito mais recursos (e dinheiro) do que um usuário americano? Um dado impressionante: usar prompt em português chega a ser 62% mais caro do que em inglês. E não, isso não tem a ver com a cotação do dólar ou planos de assinatura diferenciados para o Brasil. A explicação é puramente técnica.

Abaixo, explicamos como esse "imposto do idioma" funciona e o que você pode fazer para otimizar seus gastos e sua produtividade.

O que são Tokens e por que eles controlam o seu bolso?

Para entender o problema, primeiro precisamos entender a moeda de troca das grandes ferramentas de IA: o token.

As IAs não leem textos como nós (palavra por palavra) e também não cobram por caractere. Elas fatiam o texto em pedaços chamados tokens. Uma regra geral para o inglês é que um token equivale a mais ou menos 4 caracteres ou 0,75 palavras. Toda vez que você envia uma pergunta (input) ou recebe uma resposta (output), você paga por token.

Além disso, cada modelo tem um limite de memória interna, a chamada janela de contexto. Quanto mais tokens você gasta, mais rápido a ferramenta/agente de IA "esquece" o que foi dito no início da conversa ou estoura o limite do seu plano de desenvolvimento.

Por Que o Português é "Penalizado"?

O grande X da questão está em como os modelos de IA são treinados. Eles utilizam um algoritmo chamado BPE (Byte Pair Encoding), que analisa volumes gigantescos de texto na internet para identificar quais combinações de letras aparecem com mais frequência, transformando-as em tokens únicos.

Como a esmagadora maioria da internet e dos dados de treinamento está em inglês, o algoritmo é extremamente eficiente nesse idioma. Palavras inteiras em inglês costumam virar um único token. Já no português, por ser menos frequente na base de dados global, as palavras são frequentemente "fatiadas" em vários pedacinhos menores.

O Exemplo Prático do Vídeo:

Na ferramenta de testes, a frase em inglês "Palmeiras don't have world championship" gerou apenas 7 tokens.

A tradução exata em português, "Palmeiras não tem mundial", gerou 11 tokens para transmitir exatamente o mesmo significado.

Embora o português ainda se saia melhor do que idiomas como o árabe ou o chinês (que sofrem penalidades ainda maiores), o multiplicador médio para a nossa língua é de 1.62. Ou seja: você consome 62% mais tokens para dizer a mesma coisa.

Anthropic vs. OpenAI: O peso do design

Outro insight valioso é que esse custo varia de acordo com a empresa criadora do modelo. A Anthropic (criadora do modelo Claude, muito elogiado por desenvolvedores) tende a ser ainda mais cara para idiomas que não são o inglês do que a OpenAI (do ChatGPT).

Isso não ocorre por má intenção; é uma consequência direta das escolhas de design do tokenizador e de onde essas empresas focaram a maior parte do orçamento e dos dados de seus treinamentos iniciais.

Como agir? As 3 estratégias para o seu dia a dia

Sabendo disso, você tem três caminhos claros para escolher, dependendo do seu contexto profissional e financeiro:

• 1. Adotar o inglês como padrão

  Se você já domina o inglês ou trabalha em ambientes globais, faça seus prompts e comandos 100% em inglês. Se você usa ferramentas como o Claude Code ou ChatGPT/Codex para programar, manter o código, as instruções e a documentação em inglês vai salvar uma quantidade massiva do seu orçamento de tokens.

• 2. A abordagem híbrida

  Não se sente confortável conversando em inglês o tempo todo? Sem problemas. Você pode manter os artefatos pesados em inglês (aqueles arquivos de contexto, como um README.md, regras de negócio ou especificações técnicas que a IA precisa ler repetidamente a cada mensagem) e fazer as suas perguntas cotidianas no chat em português. O maior ganho está em economizar nos arquivos estruturais que ficam fixos na memória da IA.

• 3. Aceitar o Custo e Focar no Resultado

  Se você tem barreiras com o inglês ou se o seu projeto é pequeno e o custo não faz diferença no orçamento final, ignore os tokens e continue usando o português. No fim do dia, a clareza da sua comunicação e a velocidade da sua entrega valem mais do que alguns centavos economizados à custa de lentidão cognitiva.

Considerações finais

À medida que os modelos de IA se tornam mais poliglotas e treinados com dados globais, a tendência é que essa diferença diminua. Mas no cenário atual da tecnologia, o idioma que você escolhe para falar com a máquina dita o preço que você paga e a eficiência do contexto que ela retém.

E você? Costuma usar prompts em inglês ou português no seu projeto? Já tinha reparado na velocidade com que os seus créditos evaporam em nossa língua nativa?

Feito!

Guia Definitivo de Chaves SSH: Segurança Máxima e Conexões Práticas na sua VPS

No universo da administração de servidores, o acesso remoto via SSH (Secure Shell) é uma das ferramentas mais triviais e indispensáveis. Contudo, há uma linha tênue entre a facilidade de acesso e a vulnerabilidade do sistema. Depender exclusivamente de logins por senha deixa seus servidores expostos a ataques automatizados de força bruta de escala global.

A solução definitiva para este problema reside na implementação de autenticação por chaves SSH. Neste artigo, vamos explorar minuciosamente o conceito de par de chaves, como realizar o endurecimento de segurança (hardening) do serviço no servidor remoto, automatizar a cópia das credenciais e estruturar atalhos para otimizar drasticamente o seu fluxo de trabalho diário.

1. O Conceito Fundamental: Chave e Fechadura

Para entender chaves SSH de forma definitiva, podemos utilizar a analogia clássica de uma chave física e sua respectiva fechadura criptográfica:

• Chave Privada (Sua Chave): Permanece exclusivamente na sua máquina local. Ela nunca, sob hipótese alguma, deve ser compartilhada, transmitida ou exposta a terceiros. Ela atua como o segredo necessário para assinar as solicitações de acesso.
• Chave Pública (A Fechadura): É instalada nos servidores remotos (VPS) aos quais você deseja obter acesso. Por ser um componente público, o conhecimento dela por terceiros não compromete o sistema, uma vez que ela é matematicamente inútil se não estiver associada à chave privada correspondente.

Quando você solicita uma conexão, o cliente local e o servidor remoto utilizam conceitos de criptografia assimétrica para validar a autenticidade da sessão sem que a sua chave privada precise trafegar pela rede.

2. Gerando o Par de Chaves Criptográficas

O primeiro passo prático consiste em gerar o par de chaves na sua máquina local. Atualmente, o padrão recomendado pela indústria em termos de segurança e performance de processamento é o algoritmo ED25519, superando os legados padrões RSA.

Abra o terminal do seu computador local e execute o comando abaixo:

ssh-keygen -t ed25519 -f ~/.ssh/id_vps_root

O parâmetro -t ed25519 especifica o algoritmo moderno desejado, enquanto o -f define o caminho e o nome customizado do arquivo de identidade (evitando sobrescrever chaves genéricas pré-existentes).

Durante o processo, o utilitário solicitará uma Passphrase (frase secreta). Trata-se de uma senha que criptografa a sua própria chave privada em disco. Caso alguém consiga roubar o arquivo da sua máquina, não poderá usá-lo sem conhecer essa senha. Para rotinas altamente automatizadas, alguns profissionais optam por deixá-la vazia, o que requer uma atenção redobrada na segurança física do dispositivo local.

Após a conclusão, dois arquivos serão gerados no diretório ~/.ssh/:

• id_vps_root: O arquivo contendo a sua chave privada (sigilo absoluto).
• id_vps_root.pub: O arquivo contendo a sua chave pública (a ser exportada).

3. Exportando a Chave Pública para a VPS

Para que o servidor remoto reconheça a sua assinatura criptográfica, precisamos armazenar o conteúdo da chave pública dentro de um arquivo específico na conta do usuário remoto, localizado por padrão em ~/.ssh/authorized_keys.

Método Automatizado (Recomendado)

A maneira mais limpa e segura de realizar esse procedimento é usando o comando nativo ssh-copy-id, passando explicitamente o arquivo público gerado:

ssh-copy-id -i ~/.ssh/id_vps_root.pub usuario@ip_do_seu_servidor

O utilitário se conectará ao servidor (solicitando a senha tradicional pela última vez), criará as pastas necessárias com as permissões corretas e inserirá a chave de maneira limpa.

Método Manual (Alternativo)

Caso o utilitário automatizado não esteja disponível, você pode exibir o conteúdo da chave na sua tela, copiá-lo e inseri-lo manualmente no servidor:

cat ~/.ssh/id_vps_root.pub

No servidor remoto, você precisará colar essa string de texto dentro do arquivo ~/.ssh/authorized_keys. É de suma importância garantir as permissões rígidas exigidas pelo serviço OpenSSH, executando na VPS:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys

⚠️ Atenção Crucial às Permissões!

O OpenSSH possui salvaguardas rigorosas. Se o diretório .ssh ou o arquivo authorized_keys permitirem escrita ou leitura por outros grupos/usuários do sistema, o servidor ignorará a chave pública silenciosamente e bloqueará a conexão.

4. Hardening do Servidor: Ajustando o arquivo sshd_config

Apenas habilitar as chaves SSH não protege seu ambiente por completo se as vulnerabilidades de autenticação por senha padrão continuarem ativas. Precisamos reconfigurar o serviço SSH Daemon no servidor remoto.

Acesse sua VPS e abra o arquivo de configuração principal (utilize o editor de sua preferência com privilégios administrativos):

sudo nano /etc/ssh/sshd_config

Localize (ou adicione ao final do arquivo) as seguintes diretivas críticas detalhadas na tabela abaixo:

Diretiva de Configuração	Explicação Técnica e Impacto de Segurança
PubkeyAuthentication yes	Habilita oficialmente a validação e aceitação de conexões baseadas em chaves SSH assimétricas. Elemento mandatório da indústria.
PasswordAuthentication no	Desativa completamente o login por senhas tradicionais. Isso elimina 100% dos ataques automatizados baseados em dicionários e força bruta.
PermitRootLogin no	Impede que o usuário administrador máximo (root) realize login diretamente de fora. Obriga o acesso por uma conta de usuário comum, elevando privilégios apenas quando necessário via sudo.
PermitEmptyPasswords no	Mecanismo de salvaguarda explícito que impede acessos a contas locais que, por ventura ou erro, não possuam senha definida.

💡 Dica de Manutenção Proativa

Sistemas modernos baseados em Debian/Ubuntu frequentemente importam arquivos modulares localizados em /etc/ssh/sshd_config.d/*.conf. As diretivas são interpretadas de cima para baixo. Portanto, certifique-se de aplicar suas regras onde elas efetivamente se sobreponham aos padrões mais fracos.

Antes de aplicar as alterações, teste a sintaxe do arquivo de configuração para garantir que você não inseriu erros tipográficos que possam te trancar para fora do servidor de vez:

sudo sshd -t

Se nenhum erro for retornado, reinicie o daemon para aplicar as políticas ativas:

sudo systemctl restart ssh

5. Produtividade Máxima: Criando Atalhos Avançados (Aliases)

Após fixar as chaves, digitar comandos extensos definindo parâmetros de arquivos de identidade em todas as conexões compromete o fluxo produtivo. Para resolver isso, configuramos atalhos organizados diretamente na máquina local cliente.

No seu computador local, crie ou edite o arquivo de configuração do usuário cliente:

nano ~/.ssh/config

Adicione um bloco de configuração mapeando explicitamente a sua VPS:

Host meu-servidor
    HostName ip_ou_dominio_da_sua_vps
    User seu_usuario_remoto
    Port 22
    IdentityFile ~/.ssh/id_vps_root
    IdentitiesOnly yes

Entendendo as propriedades do bloco do cliente:

• Host meu-servidor: O alias ou pseudônimo que você escolheu. Você pode usar qualquer nome intuitivo aqui.
• HostName: O endereço IPv4 público ou domínio qualificado da VPS de destino.
• User: O nome exato do usuário remoto configurado para receber as chaves.
• IdentityFile: O caminho exato da chave privada local correspondente para esta conexão.
• IdentitiesOnly yes: Instrui o SSH a tentar estritamente a identidade configurada neste bloco, prevenindo que o agente teste chaves aleatórias em massa, o que dispararia gatilhos de segurança e rejeições por tentativas excessivas nos servidores mais rígidos.

Agora, o acesso à infraestrutura remota resume-se a um único e rápido comando no terminal:

ssh meu-servidor

O cliente lerá o arquivo config de forma transparente, carregará a identidade privada correta, mapeará as credenciais de IP e usuário adequadas e abrirá o terminal seguro de maneira imediata e robusta.

Considerações finais

A transição de autenticações tradicionais baseadas em senhas para pares de chaves assimétricas estruturadas via algoritmo ED25519 é o pilar inicial essencial de qualquer arquitetura de infraestrutura de rede resiliente. Ao combinar a segurança do endurecimento no arquivo sshd_config com o conforto operacional provido pelos blocos de configuração do cliente SSH, você eleva significativamente a maturidade de segurança da sua VPS ao mesmo tempo em que otimiza sua velocidade de operação diária.

Feito!

Como estruturar a arquitetura da ferramenta de IA do jeito certo

Se você utiliza a ferramenta de Inteligência Artificial de IA no seu dia a dia de desenvolvimento ou criação de conteúdo, provavelmente já passou por este cenário: você começa um chat com um LLM, o fluxo vai bem nas primeiras interações, mas, após algumas correções e colagens de código, a IA começa a alucinar, perder o fio da meada e entregar outputs de baixa qualidade.

Esse fenômeno não é um defeito do modelo em si, mas sim um reflexo da fadiga da janela de contexto. À medida que entupimos o histórico com tentativas e erros, o poder de raciocínio do modelo degrada. Para mitigar isso, profissionais estão evoluindo o uso de ferramentas como o Claude Code, ChatGPT/Codex, Gemini e etc de simples caixas de chat para ecossistemas maduros.

Para extrair o máximo valor dos LLMs com eficiência, performance e baixo custo, o mercado de tecnologia está migrando do Prompt Engineering casual para a verdadeira Arquitetura de IA. A seguir, vamos entender como essa estrutura se divide entre Harness, Skills, Agents e Subagents.

O coração da estrutura: O que é o Harness?

Muitas vezes confundido com engenharia de contexto, o Harness é a infraestrutura de software que encapsula o LLM (o motor de raciocínio). Enquanto o modelo apenas processa texto, o Harness dita as regras arquiteturais do sistema:

• Permissões e Segurança: Define se a IA pode alterar arquivos diretamente na IDE ou se precisa de aprovação manual.
• Gestão de Estado: Gerencia o que deve ser mantido como memória persistente a longo prazo e o que é apenas um estado temporário da execução atual.
• Ciclo de Instruções: Determina quais diretrizes e guias técnicos (como arquivos Markdown de especificação) entram no contexto do modelo em cada etapa.

Com um Harness bem desenhado, você elimina a necessidade de repetir regras de boas práticas em cada prompt enviado, automatizando o alinhamento de contexto.

Skills vs. Agents: Quando usar cada abordagem?

Uma das maiores confusões atuais é chamar qualquer automação simples de "Agente". Na arquitetura moderna, dividimos a execução de tarefas de forma clara com base na previsibilidade do escopo.

1. Skills (habilidades reutilizáveis e previsíveis)

As Skills são pacotes de instruções padronizados e reutilizáveis voltados para processos conhecidos. Quando você sabe exatamente as etapas do fluxo de trabalho e precisa de um resultado padronizado, você desenha uma skill.

• Foco principal: Previsibilidade e economia de tokens de contexto.
• Exemplos: Gerar propostas comerciais em um formato fixo, rodar um checklist de Code Review ou criar metadados padronizados para vídeos.
• Reutilização: Uma mesma habilidade pode ser acoplada a múltiplos componentes do seu sistema sem reescrever o código base.

2. Agents (ciclos de ação autônomos)

Um Agent entra em cena quando enfrentamos processos investigativos ou de escopo desconhecido. Em vez de apenas gerar um texto estático, o agente opera dentro de um loop dinâmico de ação (agent loop): ele analisa o problema, planeja os passos, executa e valida o resultado de forma autônoma.

• O papel do MCP: Graças ao surgimento do Model Context Protocol (MCP), os agentes ganharam uma interface universal para se conectar a ferramentas externas (bancos de dados, APIs e sistemas de arquivos), permitindo ações robustas no mundo real.

Visualizando a Arquitetura Híbrida

O segredo da manutenção da performance é a aplicação do componente correto para o problema certo. Abaixo, ilustramos como um Agente atua como orquestrador de escopos:

Cenário Arquitetural: Fluxo Híbrido de IA

Otimizando a Janela de Contexto com Subagents

Para evitar a saturação da memória do chat principal, a arquitetura moderna delega escopos. Quando um agente principal recebe uma macro-tarefa que envolve varredura de logs ou pesquisas longas, ele invoca um Subagent em uma janela paralela.

O subagente consome os tokens necessários para aquela micro-investigação, resolve o problema e devolve apenas o dado consolidado para o fluxo principal. Isso protege a experiência de uso contra o desperdício de recursos e falhas de alucinação.

Nota de Automatização Consciente: Nem tudo precisa de utilizar uma ferramenta de Inteligência Artificial (IA). Se o processo é estritamente mecânico (como mover arquivos ou converter formatos), utilize scripts convencionais em lote ou ferramentas de pipeline. Deixe os LLMs para etapas que demandam interpretação pura.

Considerações finais

O mercado de tecnologia está deixando para trás a fase do empirismo de prompts copiados e colados. O próximo nível profissional exige a capacidade de sistematizar o conhecimento em software, desenhando arquiteturas capazes de entregar alta qualidade com o menor consumo de recursos possível. Ao estruturar seu fluxo com componentes modulares, você garante escalabilidade e robustez na engenharia de soluções orientadas a IA.

DDD explicado de forma didática

Domain-Driven Design: como modelar software complexo colocando o domínio no centro do universo

O que é DDD?

Domain-Driven Design (DDD) é uma abordagem de desenvolvimento de software criada por Eric Evans no livro azul de 2003. O nome pode assustar, mas a ideia é simples: em vez de começar pensando em bancos de dados, rotas HTTP ou frameworks, você começa pensando no domínio do negócio, ou seja, no problema que o software precisa resolver.

DDD não é uma tecnologia, nem um framework, nem uma arquitetura como MVC. É um conjunto de princípios e padrões que ajuda times de software a criar modelos mentais compartilhados com especialistas do negócio.

"O coração do software é a capacidade de resolver problemas do domínio." Eric Evans

Por que DDD existe?

Projetos de software falham com frequência porque o time técnico e os especialistas do negócio não falam a mesma língua. O desenvolvedor pergunta "qual o tipo desse campo?"; o especialista responde "é o código da agência". Ninguém se entende. O resultado são sistemas cheios de regras espalhadas, modelos anêmicos e código que ninguém consegue mudar sem quebrar tudo.

DDD propõe uma linguagem comum (chamada de Ubiquitous Language) usada por todos, do analista ao dev ao QA, e um modelo de software que reflete fielmente essa linguagem.

Os pilares do DDD

1. Linguagem Ubíqua (Ubiquitous Language)

É o vocabulário compartilhado entre todos os envolvidos. Se o especialista chama algo de "Transferência", o código deve ter uma classe Transferencia, a tabela deve se chamar transferencias, e a API deve expor /transferencias. Nada de Trans, TransfRecord ou transactions, usem o mesmo nome.

2. Domínio e Subdomínios

O domínio é o coração do negócio, é o problema principal que o sistema resolve. Um único sistema grande geralmente contém vários subdomínios:

• Core Domain: a parte mais importante, que dá vantagem competitiva. Ex: o motor de precificação de um banco.
• Supporting Subdomain: necessário, mas não estratégico. Ex: cálculo de impostos.
• Generic Subdomain: pode ser comprado ou usado pronto. Ex: autenticação, envio de e-mail.

// Exemplo: o domínio de um sistema bancário
// Core Domain: Motor de crédito
class AnaliseDeCredito {
  constructor(private score: Score, 
  private rendaMonetaria: Renda) {}
  aprovar(): boolean {
      /* lógica de negócio central */
      }
}

// Supporting Subdomain: Cálculo de tarifas
class CalculadoraDeTarifas {
  calcular(operacao: Operacao): number { 
  /* complexo, mas não estratégico */ }
}

// Generic Subdomain: Autenticação (pronto, comprado)
// Usamos Keycloak, Auth0, ou similar

3. Contextos Delimitados (Bounded Contexts)

Um dos conceitos mais importantes do DDD. Um Bounded Context é uma fronteira explícita dentro da qual um modelo de domínio é válido. Dentro dela, a Linguagem Ubíqua tem significado único e consistente.

Por exemplo: no contexto de Vendas, "Cliente" tem endereço de entrega e histórico de pedidos. No contexto de Cobrança, "Cliente" tem CPF, score de crédito e data de vencimento. São modelos diferentes e devem viver em contextos separados (serviços, módulos, ou até repositórios distintos).

Cada Bounded Context pode ter sua própria arquitetura, seu próprio banco de dados e sua própria equipe. O que vale dentro de um, não vale dentro do outro.

Os blocos de construção táticos

DDD fornece padrões de modelagem para transformar a linguagem do negócio em código expressivo.

Entity

Um objeto que tem identidade própria. Dois objetos com os mesmos atributos mas identidades diferentes são entidades diferentes. Ex: um Cliente com id = 123 é diferente do cliente id = 456, mesmo que tenham o mesmo nome.

class Cliente {
  constructor(
    // identidade única
    readonly id: ClienteId,  
    private nome: Nome,
    private email: Email
  ) {}

  trocarEmail(novoEmail: Email): void {
    this.email = novoEmail;
  }
}

Value Object

Um objeto que não tem identidade, é definido apenas pelos seus atributos. Dois Value Objects com os mesmos valores são considerados iguais. São imutáveis.

• Dinheiro (valor + moeda), R$ 50,00 não deixa de ser R$ 50,00 por ter "identidade".
• CPF, Email, Endereco, todos imutáveis e comparados por valor.

class Dinheiro {
  constructor(
    readonly valor: number,
     // 'BRL', 'USD'
    readonly moeda: string 
  ) {}

  somar(outro: Dinheiro): Dinheiro {
    if (this.moeda !== outro.moeda)
      throw new Error('Moedas diferentes');
    return new Dinheiro(this.valor + 
                       outro.valor, this.moeda);
  }

  equals(outro: Dinheiro): boolean {
    return this.valor === outro.valor && 
               this.moeda === outro.moeda;
  }
}

Aggregate

Um cluster de objetos tratados como uma unidade. Cada Aggregate tem uma raiz (Aggregate Root) que é a única porta de entrada para o mundo externo. Toda consistência do cluster passa pela raiz.

// Aggregate Root: Pedido
class Pedido {
  constructor(
    readonly id: PedidoId,
    readonly clienteId: ClienteId,
    private itens: Item[],
    private status: StatusPedido
  ) {}

  adicionarItem(produto: Produto, 
    quantidade: number): void {
    if (this.status !== 'aberto')
      throw new Error('Pedido fechado não aceita itens');
    this.itens.push(new Item(produto, quantidade));
  }

  total(): Dinheiro {
    return this.itens.reduce(
      (acc, item) => acc.somar(item.subtotal()),
      new Dinheiro(0, 'BRL')
    );
  }
}

Domain Event

Algo que aconteceu no domínio e interessa a outras partes do sistema. Usa-se verbos no passado: PedidoCriado, TransferenciaRealizada, ContaEncerrada.

class PedidoCriado {
  constructor(
    readonly pedidoId: PedidoId,
    readonly clienteId: ClienteId,
    readonly total: Dinheiro,
    readonly ocorridoEm: Date = new Date()
  ) {}
}

Repository

Abstração de persistência. Para o domínio, o Repository parece um coleção em memória. O domínio nunca sabe se está usando PostgreSQL, MongoDB ou arquivo JSON.

interface PedidoRepository {
  salvar(pedido: Pedido): Promise<void>;
  buscarPorId(id: PedidoId): Promise<Pedido | null>;
  buscarPorCliente(clienteId: ClienteId): Promise<
                                          Pedido[]>;
}

Domain Service

Quando uma operação não pertence naturalmente a uma Entity ou Value Object, criamos um Domain Service. Ele orquestra regras que envolvem múltiplos agregados.

class ServicoDeTransferencia {
  constructor(
    private contas: ContaRepository
  ) {}

  transferir(origemId: ContaId, destinoId: 
  ContaId, valor: Dinheiro): void {
    const origem = this.contas.buscarPorId(origemId);
    const destino = this.contas.buscarPorId(destinoId);

    origem.debitar(valor);
    destino.creditar(valor);

    this.contas.salvar(origem);
    this.contas.salvar(destino);
  }
}

DDD e arquitetura

DDD não exige uma arquitetura específica, mas se encaixa perfeitamente com Arquitetura Hexagonal (Ports & Adapters) e Clean Architecture. A regra de ouro é:

• O domínio fica no centro, isolado de frameworks, banco de dados e UI.
• A infraestrutura (HTTP, banco, filas) fica nas bordas e depende do domínio, não o contrário.
• As dependências apontam para dentro (Dependency Inversion Principle).

src/
├── dominio/    # CORE  sem dependências externas
│   ├── entidades/
│   ├── value-objects/
│   ├── servicos/
│   └── repositorios/ # Interfaces apenas
├── aplicacao/        # Casos de uso (orquestração)
├── infra/            # Implementações concretas
│   ├── persistencia/
│   ├── http/
│   └── fila/
└── shared/           # Código compartilhado

Quando usar DDD?

• Use quando o domínio do negócio é complexo e cheio de regras.
• Use quando há especialistas de negócio dispostos a conversar com o time técnico.
• Não use em CRUDs simples um formulário que só insere dados no banco não precisa de DDD.
• Não use se o time não tem disciplina para manter a Linguagem Ubíqua viva.
• Não use como dogma DDD é ferramenta, não religião.

Passos práticos para começar

1. Entreviste especialistas sente com quem entende do negócio e faça perguntas. Anote os termos que eles usam.
2. Crie um glossário monte a Linguagem Ubíqua com definições claras de cada termo.
3. Identifique os Bounded Contexts desenhe fronteiras: o que faz parte de Vendas? O que faz parte de Cobrança?
4. Modele os Aggregates descubra as raízes e o que pertence a cada uma.
5. Implemente com TDD o domínio é a parte mais testável do sistema. Teste as regras de negócio sem tocar em banco ou HTTP.
6. Refatore sem medo o modelo de domínio evolve com o negócio. DDD favorece a mudança.

Exemplo completo: Aluguel de Carros

Vamos modelar um pequeno domínio de locação de veículos usando DDD:

// ——— Value Objects ———
class Placa {
  constructor(readonly valor: string) {
    if (!/^[A-Z]{3}\d[A-Z]\d{2}$/.test(valor))
      throw new Error('Placa inválida');
  }
}

class Quilometragem {
  constructor(readonly valor: number) {
    if (valor < 0) throw new 
    Error('KM não pode ser negativo');
  }
}

class Periodo {
  constructor(readonly inicio: Date, 
  readonly fim: Date) {
    if (fim <= inicio) throw new 
    Error('Período inválido');
  }
  duracaoDias(): number {
    return (this.fim.getTime() - 
    this.inicio.getTime()) / 86400000;
  }
}

// ——— Aggregate: Veiculo ———
class Veiculo {
  constructor(
    readonly id: VeiculoId,
    readonly placa: Placa,
    private kmAtual: Quilometragem,
    private disponivel: boolean = true
  ) {}

  alugar(): void {
    if (!this.disponivel) throw new 
    Error('Veículo indisponível');
    this.disponivel = false;
  }

  registrarDevolucao(kmFinal: Quilometragem): void {
    this.disponivel = true;
    this.kmAtual = kmFinal;
  }
}

// ——— Aggregate: Locacao ———
class Locacao {
  constructor(
    readonly id: LocacaoId,
    readonly veiculoId: VeiculoId,
    readonly clienteId: ClienteId,
    readonly periodo: Periodo,
    readonly tarifaDiaria: Dinheiro,
    private status: 'ativa' | 'finalizada' = 'ativa'
  ) {}

  calcularTotal(): Dinheiro {
    const dias = this.periodo.duracaoDias();
    return new Dinheiro(dias * 
           this.tarifaDiaria.valor, 'BRL');
  }

  finalizar(): void {
    if (this.status === 'finalizada')
      throw new Error('Locação já finalizada');
    this.status = 'finalizada';
  }
}

// ——— Domain Event ———
class VeiculoAlugado {
  constructor(
    readonly veiculoId: VeiculoId,
    readonly locacaoId: LocacaoId,
    readonly clienteId: ClienteId
  ) {}
}

// ——— Repository (interface) ———
interface VeiculoRepository {
  salvar(veiculo: Veiculo): Promise<void>;
  buscarDisponivel(): Promise<Veiculo[]>;
  buscarPorId(id: VeiculoId): Promise<Veiculo | null>;
}

Para se aprofundar

• Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans (o "livro azul")
• Implementing Domain-Driven Design Vaughn Vernon (o "livro vermelho")
• Domain-Driven Design Distilled Vaughn Vernon (resumo prático, ótimo para começar)
• DDD: The First 15 Years Artigos de diversos autores sobre a evolução do DDD

Considerações finais

DDD não é sobre diagramas bonitos ou arquitetura sofisticada. É sobre comunicação. É sobre criar um modelo de software que qualquer pessoa do negócio consegue ler e validar. É sobre colocar a complexidade do domínio no centro e usar padrões que a tornem controlável.

Comece pequeno: escolha um Bounded Context, crie a Linguagem Ubíqua com um especialista, modele alguns Aggregates e escreva testes. O resto vem com a prática.

DDD é uma jornada, não um destino.

Feito!