AWS
Design e operação de soluções na nuvem AWS: EC2, Lambda, ECS, RDS, DynamoDB, S3, API Gateway, EventBridge e SQS. Foco em arquiteturas serverless, event-driven e bem-arquitetadas.
01 — Sobre
Duas décadas construindo software
Sou um Arquiteto de Software com mais de 20 anos de experiência em desenvolvimento de sistemas. Ao longo da carreira, atuei em projetos de diferentes escalas e domínios, sempre com foco em entregar soluções robustas, escaláveis e que evoluem com o negócio.
Minha paixão está em transformar problemas complexos em arquiteturas elegantes, aplicando princípios sólidos de engenharia de software como Domain-Driven Design, Clean Architecture e Clean Code. Acredito que código bem escrito é uma forma de respeito pelas pessoas que vão mantê-lo.
Trabalho na intersecção entre negócio e tecnologia, ajudando equipes a entregar valor de forma consistente e sustentável.
0
Anos de experiência
0
Projetos entregues
0
Devs mentorados
∞
Curiosidade técnica
02 — Skills
Tecnologias e práticas
Claude & IA
Desenvolvimento de soluções com Claude (Anthropic) e LLMs: integrações via MCP, prompt engineering, RAG, tool use e agentes autônomos para automação de fluxos de negócio.
Infrastructure as Code
Provisionamento e gestão de infraestrutura com Terraform, AWS CDK e CloudFormation. Pipelines CI/CD, GitOps e observabilidade como parte do design da plataforma.
Sistemas Distribuídos
Arquitetura de microsserviços, mensageria assíncrona, event sourcing, CQRS, consistência eventual, saga pattern e resiliência (circuit breakers, retries, idempotência).
Domain-Driven Design
Modelagem estratégica e tática: bounded contexts, ubiquitous language, agregados, value objects, domain events e context mapping aplicados a problemas reais.
Clean Architecture
Aplicação rigorosa dos princípios SOLID, inversão de dependência, separação de camadas e testabilidade. Código que comunica intenção antes de implementação.
03 — Conceito
Domain-Driven Design
Baseado em "Domain-Driven Design: Tackling Complexity in the Heart of Software" — Eric Evans, 2003
"O coração do software é a sua capacidade de resolver problemas relacionados ao domínio do seu usuário."
— Eric Evans
Domain-Driven Design (DDD) é uma abordagem para o desenvolvimento de software complexo na qual o foco principal é o domínio do negócio e sua lógica. Eric Evans propõe que o sucesso de um sistema depende menos da tecnologia escolhida e mais da capacidade da equipe em modelar profundamente o problema que está sendo resolvido.
Ubiquitous Language
Uma linguagem ubíqua é compartilhada entre desenvolvedores e especialistas do domínio. Cada termo no código reflete um conceito real do negócio, eliminando traduções mentais que geram bugs e mal-entendidos. O modelo é a linguagem.
Bounded Context
Um contexto delimitado define uma fronteira explícita dentro da qual um modelo é consistente. Em sistemas grandes, conceitos como "Cliente" ou "Produto" podem significar coisas diferentes em contextos diferentes — e está tudo bem, desde que as fronteiras estejam claras.
Entities & Value Objects
Entidades têm identidade que persiste ao longo do tempo (um Cliente, um Pedido). Value Objects são definidos apenas por seus atributos e são imutáveis (um endereço, uma quantia em dinheiro). Distinguir os dois é fundamental para um modelo limpo.
Aggregates
Um agregado é um cluster de objetos tratado como uma unidade para fins de mudança de dados. Possui uma raiz (aggregate root) que garante a consistência das invariantes de negócio, protegendo o modelo de estados inválidos.
Domain Events
Eventos de domínio capturam algo significativo que aconteceu no negócio ("PedidoFoiPago", "ClienteSeRegistrou"). São o pilar de arquiteturas event-driven e permitem que diferentes partes do sistema reajam de forma desacoplada.
Strategic Design
Além das táticas, DDD oferece ferramentas estratégicas: context mapping, identificação do core domain (onde está a vantagem competitiva) e relacionamentos entre times (customer/supplier, anticorruption layer, shared kernel).
A filosofia por trás
DDD não é sobre frameworks ou padrões — é sobre colaboração profunda com quem entende do negócio. Evans defende um modelo que é destilado iterativamente, em que cada conversa com um especialista de domínio aprofunda nossa compreensão e refina o código. O modelo não é desenhado antes do código; o código é o modelo.
04 — Conceito
Clean Architecture & Clean Code
Baseado em "Clean Code" (2008) e "Clean Architecture" (2017) — Robert C. Martin (Uncle Bob)
"A única medida válida da qualidade de um código é: WTFs por minuto."
— Robert C. Martin
Clean Code: o livro
Em Clean Code, Uncle Bob defende que escrever código é um ato de comunicação. Código não é escrito para máquinas — é escrito para seres humanos que vão lê-lo, mantê-lo e estendê-lo. A máquina é apenas uma consumidora secundária.
- Nomes significativos: variáveis, funções e classes devem revelar intenção. Nada de
x,tmpouprocessData(). - Funções pequenas: devem fazer uma coisa só, bem feita, no mesmo nível de abstração.
- Comentários: são frequentemente um sintoma de código que falhou em se explicar. Bom código se documenta.
- Tratamento de erros: não polui a lógica de negócio. Use exceções, não códigos de retorno.
- Testes limpos: seguem F.I.R.S.T. (Fast, Independent, Repeatable, Self-Validating, Timely).
- A Regra do Escoteiro: deixe o código sempre mais limpo do que você o encontrou.
Clean Architecture: o livro
Em Clean Architecture, Martin generaliza os princípios para o nível arquitetural. A grande regra é a Regra da Dependência: dependências sempre apontam para dentro, em direção às políticas de negócio. Detalhes (frameworks, bancos de dados, UI) dependem de abstrações — nunca o contrário.
Quanto mais interno o círculo, mais estável e independente de detalhes técnicos.
SOLID: os cinco princípios
Sustentando tudo isso, os princípios SOLID formam a base para classes e módulos bem desenhados:
S
Single Responsibility
Um módulo deve ter uma — e apenas uma — razão para mudar.
O
Open/Closed
Aberto para extensão, fechado para modificação.
L
Liskov Substitution
Subtipos devem ser substituíveis pelos seus tipos base sem quebrar o sistema.
I
Interface Segregation
Clientes não devem ser forçados a depender de interfaces que não usam.
D
Dependency Inversion
Dependa de abstrações, não de implementações concretas.
A grande lição de Uncle Bob é que arquitetura é sobre adiar decisões. Uma boa arquitetura mantém as opções abertas pelo maior tempo possível, isolando as regras de negócio das escolhas técnicas que mudam — frameworks, bancos, bibliotecas. O resultado: sistemas que sobrevivem ao tempo.
05 — Contato
Vamos conversar?
Se você tem um desafio de arquitetura, está repensando seu sistema ou quer trocar ideias sobre engenharia de software, ficarei feliz em conversar.