Além do CRUD: construindo projetos pessoais para validar arquitetura, cloud e automação · devDenner

Durante muito tempo, quando alguém falava em “projeto de portfólio” na área de tecnologia, o caminho mais comum era quase sempre o mesmo: criar um sistema com cadastro, login, listagem, edição e exclusão de registros.

Em outras palavras: um CRUD.

E não há nada de errado com isso.

CRUDs são importantes. Eles ajudam a demonstrar fundamentos, organização de código, integração com banco de dados, validações, autenticação, interface e fluxo básico de uma aplicação.

Mas, depois de alguns anos trabalhando com desenvolvimento, integrações, regras de negócio, infraestrutura, automação e sistemas em produção, comecei a perceber uma limitação nesse tipo de projeto: ele nem sempre mostra como a pessoa pensa arquiteturalmente.

Ele mostra que você sabe implementar telas e endpoints.

Mas nem sempre mostra que você sabe lidar com decisões técnicas mais próximas da vida real.

Por isso, decidi reorganizar meu portfólio público com uma proposta diferente: construir projetos pessoais que sejam pequenos o suficiente para manter, mas ricos o bastante para demonstrar arquitetura, cloud, automação, testes, modelagem de domínio e uso aplicado de IA.

A ideia não é criar “sistemas gigantes”.
A ideia é criar laboratórios técnicos com problemas reais.

O problema dos projetos genéricos

Muitos projetos de portfólio acabam ficando presos a uma estrutura muito parecida:

cadastro de usuários;
login;
tela de listagem;
formulário de criação;
botão de editar;
botão de excluir;
algum dashboard simples;
deploy básico.

Isso pode ser suficiente para mostrar conhecimento inicial, mas para quem quer demonstrar senioridade, talvez falte uma camada importante: decisão técnica.

Na prática, sistemas reais costumam exigir perguntas mais complexas:

Como o domínio está modelado?
Como os dados evoluem ao longo do tempo?
Como o sistema reage a eventos?
Como lidar com falhas?
Como registrar auditoria?
Como provisionar infraestrutura?
Como automatizar validações?
Como separar regra de negócio de detalhes de framework?
Como integrar serviços externos sem acoplamento excessivo?
Como testar comportamentos críticos?
Como documentar decisões arquiteturais?

Essas perguntas são mais difíceis de demonstrar em um CRUD genérico.

Por isso, comecei a pensar em projetos de portfólio menos como “aplicações para mostrar tela” e mais como laboratórios de engenharia de software.

O que quero demonstrar

Meu objetivo com esses projetos é validar algumas competências que considero importantes para desenvolvimento backend, fullstack, cloud e automação:

modelagem de domínio;
arquitetura orientada a eventos;
TypeScript aplicado a regras de negócio;
infraestrutura como código;
uso de serviços cloud;
CI/CD;
testes automatizados;
observabilidade e auditoria;
integração com IA de forma desacoplada;
documentação de decisões técnicas;
construção de produto com escopo controlado.

A ideia é que cada projeto público consiga responder a uma pergunta técnica clara.

Por exemplo:

Como modelar um fluxo financeiro assíncrono usando eventos?

Ou:

Como integrar IA a um produto sem deixar a regra de negócio presa em prompts soltos?

Ou ainda:

Como organizar campanhas, conteúdo, métricas e aprendizado em um sistema de crescimento?

Essas perguntas tornam o projeto mais interessante do que simplesmente mostrar uma lista de registros no banco.

Projeto pessoal não precisa ser pequeno demais

Existe uma armadilha comum em portfólio: achar que projeto pessoal precisa ser extremamente simples para ser finalizado rápido.

Eu concordo que o escopo precisa ser controlado. Mas controlado não significa superficial.

Um projeto pequeno pode ter boas decisões arquiteturais.

Ele pode ter:

domínio bem definido;
eventos tipados;
testes de regras de negócio;
documentação clara;
diagrama de arquitetura;
pipeline de CI;
Terraform;
separação entre aplicação e infraestrutura;
logs estruturados;
decisões registradas em ADRs.

Nada disso exige um sistema enorme.

O segredo é escolher um recorte pequeno, mas tratá-lo com seriedade.

Laboratório 1: arquitetura orientada a eventos com AWS

Um dos projetos que pretendo construir é um laboratório técnico de portabilidade de crédito usando arquitetura orientada a eventos.

A proposta é criar uma simulação educacional de um fluxo financeiro com múltiplas etapas, mudança de estados, eventos assíncronos e trilha de auditoria.

A stack planejada inclui:

TypeScript
AWS EventBridge
AWS Lambda
Amazon SQS
DynamoDB
Terraform
GitHub Actions
Vitest

O objetivo não é implementar uma especificação oficial ou reproduzir um sistema regulatório real. A ideia é usar um domínio financeiro como base para explorar conceitos técnicos importantes.

Um fluxo simplificado poderia ser:

Cliente solicita portabilidade
        ↓
API registra solicitação
        ↓
Evento: portability.request.created
        ↓
EventBridge roteia o evento
        ↓
Workers processam etapas assíncronas
        ↓
Status da solicitação é atualizado
        ↓
Eventos de auditoria são registrados

Alguns eventos possíveis:

portability.request.created
consent.authorized
source.institution.notified
credit.contract.loaded
proposal.created
proposal.accepted
portability.completed
portability.rejected
portability.failed

Esse tipo de projeto permite demonstrar vários pontos relevantes:

desenho de eventos;
separação entre comandos e eventos;
processamento assíncrono;
roteamento com EventBridge;
filas com SQS;
funções Lambda;
persistência em DynamoDB;
provisionamento com Terraform;
auditoria;
idempotência;
tratamento de falhas;
automação de infraestrutura.

É muito mais interessante tecnicamente do que apenas cadastrar propostas em uma tabela.

Terraform como parte do projeto, não como detalhe

Outro ponto importante é tratar infraestrutura como parte do código.

Em vez de apenas criar recursos manualmente no console da AWS, a ideia é provisionar tudo com Terraform.

Isso torna a arquitetura mais explícita e reprodutível.

Um projeto assim poderia ter uma estrutura como:

credit-portability-event-lab/
  apps/
    api/
    workers/
  packages/
    domain/
    events/
  infra/
    terraform/
      main.tf
      variables.tf
      outputs.tf
      modules/
        eventbridge/
        lambda/
        sqs/
        dynamodb/
        iam/
  docs/
    architecture.md
    event-catalog.md
    decisions/
  .github/
    workflows/
      ci.yml
      terraform-plan.yml

A infraestrutura deixa de ser algo “fora do projeto” e passa a fazer parte da entrega técnica.

Isso também ajuda quem está avaliando o repositório a entender não apenas o código da aplicação, mas o ambiente onde ela roda.

Laboratório 2: IA aplicada sem acoplamento a prompts

Outro tema que quero explorar é IA aplicada em produtos.

Hoje é relativamente simples adicionar uma chamada para um modelo de IA dentro de uma aplicação. Mas integrar IA de forma responsável exige mais do que montar um prompt e esperar uma resposta.

Algumas perguntas importantes aparecem rapidamente:

Como trocar de provedor de IA sem reescrever o produto?
Como validar entradas e saídas?
Como auditar o contexto usado?
Como evitar que regra de negócio fique escondida dentro de prompts?
Como lidar com fallback?
Como testar fluxos sem depender de chamadas reais?
Como separar intenção do usuário da execução técnica?

Uma abordagem possível é tratar IA como uma capacidade arquitetural.

Em vez de o produto pensar diretamente em um prompt como:

"Gere um roteiro para um vídeo de campanha"

ele poderia trabalhar com uma intenção estruturada:

intent: generate_content_brief
context:
  campaign: ...
  audience: ...
  objective: ...
constraints:
  platform: instagram_reels
  format: short_video
  tone: ...
output:
  type: structured_brief

Com isso, a aplicação não fica presa a um texto solto ou a um fornecedor específico. Ela passa a operar sobre contratos.

Esse tipo de abordagem permite criar:

adapters para diferentes provedores;
provedores mock para testes;
fallback entre modelos;
normalização de resposta;
logs estruturados;
métricas de custo e latência;
validação com schemas.

Esse é um dos pontos que mais quero destacar nos meus projetos: IA não como mágica, mas como engenharia de software.

Laboratório 3: produto e crescimento

Além da parte de cloud e IA, também quero construir um projeto voltado a produto: um sistema para organizar campanhas, conteúdo, briefs, métricas e aprendizados.

A ideia é partir de uma dor comum: muita gente produz conteúdo, testa campanhas e usa ferramentas diferentes, mas o histórico fica fragmentado.

O sistema teria conceitos como:

Campaign
ContentPlan
ContentObjective
Content
AiBrief
KnowledgeItem
StorySequence
Metric
Learning

O objetivo seria responder perguntas como:

quais campanhas estão em andamento?
quais conteúdos precisam ser produzidos?
quais conteúdos estão atrasados?
qual objetivo cada conteúdo atende?
quais ideias ainda precisam virar roteiro?
quais conteúdos foram publicados?
o que aprendemos com os resultados?
que tipo de conteúdo vale repetir?

Esse projeto seria menos sobre cloud pesada e mais sobre modelagem de domínio, produto, UX, TypeScript, Next.js, Prisma e IA aplicada.

A stack poderia ser:

Next.js
React
TypeScript
Prisma
PostgreSQL
Tailwind
shadcn/ui
Vitest

Ele serviria como laboratório para demonstrar construção de produto completo, sem depender de infraestrutura complexa.

O que diferencia esses projetos

A principal diferença entre esses projetos e um CRUD tradicional não está apenas nas tecnologias usadas.

Está na intenção.

Um CRUD normalmente demonstra implementação.

Esses projetos tentam demonstrar decisões.

Decisões como:

por que usar eventos?
onde persistir estado?
como versionar contratos?
o que deve ser síncrono ou assíncrono?
quais falhas precisam ser previstas?
como auditar uma decisão?
como separar domínio de infraestrutura?
como testar regra de negócio?
como evitar acoplamento com fornecedor?
como manter o escopo pequeno sem perder valor técnico?

Essas decisões são mais próximas do trabalho real de engenharia.

Documentação também faz parte do portfólio

Um ponto que quero levar mais a sério é a documentação.

Não adianta publicar um repositório com código interessante se ninguém entende rapidamente:

qual problema ele resolve;
como rodar localmente;
qual arquitetura foi escolhida;
quais decisões foram tomadas;
quais trade-offs existem;
quais são os próximos passos.

Por isso, cada projeto deve ter, no mínimo:

README.md
docs/architecture.md
docs/event-catalog.md
docs/decisions/
docs/roadmap.md

Também pretendo usar ADRs para registrar decisões arquiteturais importantes.

Um ADR simples pode responder:

qual era o contexto;
qual decisão foi tomada;
quais alternativas foram consideradas;
quais consequências essa decisão traz.

Isso ajuda a mostrar raciocínio técnico, não apenas código final.

CI/CD e qualidade

Outro ponto importante é automação.

Mesmo em projeto pessoal, quero incluir pipelines básicos de validação:

lint
typecheck
test
build
terraform fmt
terraform validate
terraform plan

Isso mostra cuidado com qualidade e reprodutibilidade.

Um fluxo simples de CI com GitHub Actions já é suficiente para demonstrar maturidade técnica.

A ideia não é criar burocracia, mas deixar claro que o projeto foi pensado como software que pode evoluir.

O que eu espero aprender

Esses projetos também são uma forma de estudo.

Quero aprofundar alguns temas específicos:

EventBridge em cenários de integração;
desenho de catálogos de eventos;
Terraform modular;
arquitetura serverless;
testes de domínio em TypeScript;
integração segura com IA;
modelagem de produto;
separação entre aplicação, domínio e infraestrutura;
observabilidade mínima;
documentação técnica para projetos públicos.

O objetivo não é fingir que um projeto pessoal substitui um ambiente real de produção.

Não substitui.

Mas um bom projeto pessoal pode mostrar como uma pessoa pensa, organiza problemas e toma decisões.

E isso tem muito valor.

Como pretendo publicar

A ideia é manter os projetos públicos no GitHub, com documentação e evolução incremental.

Também pretendo compartilhar alguns aprendizados em artigos e posts técnicos, mostrando o processo de construção:

escolha do domínio;
desenho da arquitetura;
definição dos eventos;
criação da infraestrutura;
testes;
erros encontrados;
ajustes de escopo;
decisões que mudaram no caminho.

Mais do que postar apenas o resultado final, quero mostrar a construção.

Porque, na prática, engenharia de software é muito mais sobre processo e tomada de decisão do que sobre uma tela pronta.

Conclusão

Projetos pessoais podem ser mais do que exercícios de CRUD.

Eles podem ser laboratórios para validar arquitetura, cloud, automação, produto e IA aplicada.

Não precisam ser enormes.
Não precisam tentar resolver o mundo.
Mas precisam ter intenção técnica clara.

No meu caso, quero usar esses projetos para demonstrar como penso sistemas: partindo de domínio, passando por arquitetura, infraestrutura, testes, automação e documentação.

No fim, o que quero mostrar não é apenas que sei escrever código.

Quero mostrar que sei construir software com contexto, decisão e propósito.