DEV Community: André N. Darcie

Agentes de IA exigem TDD: o passo a passo necessário para aplicar na prática [PT-BR]

André N. Darcie — Tue, 17 Mar 2026 20:59:35 +0000

Este tutorial mostra como usar um agente de IA para praticar TDD do zero, partindo de um requisito escrito em linguagem simples até uma implementação refatorada e com testes passando.

O exemplo é um caso de uso simples/abstraido: criar conta de usuário.

O que é TDD?

TDD (Test-Driven Development) é uma técnica de desenvolvimento em três fases:

Fase	O que fazer
RED	Escrever os testes antes do código. Eles devem falhar.
GREEN	Escrever o mínimo de código para os testes passarem.
REFACTOR	Melhorar o código sem quebrar os testes.

Ameaça e defesa

Passo 1: Definir os requisitos

Antes de escrever qualquer código, escreva o que o sistema precisa fazer em linguagem simples. Use a IA para transformar isso em um documento de requisitos.

Prompt:

Crie um arquivo .md simples, listando os requisitos
necessários para criar um caso de uso de criar 
conta de usuário com nome, e-mail e senha,
apenas com o básico.

Resultado:

# Criar Conta

## O que é isso?
Permite que uma pessoa crie uma conta na plataforma informando seu nome, e-mail e senha.

## O que o usuário precisa informar?
- Nome
- E-mail
- Senha

## Quando o cadastro é recusado?

| Situação | Motivo |
|----------|--------|
| Nome não foi preenchido | O nome é obrigatório |
| Nome tem menos de 3 letras | Nome muito curto para ser válido |
| E-mail não foi preenchido | O e-mail é obrigatório |
| E-mail está no formato errado | Precisa seguir o padrão nome@dominio.com |
| E-mail já foi usado em outro cadastro | Cada conta precisa ter um e-mail único |
| Senha tem menos de 8 caracteres | Senha muito curta |
| Senha não tem letras e números ao mesmo tempo | Senha fraca demais |

## O que acontece quando o cadastro dá certo?
A conta é criada e o sistema confirma com:
- Código único da conta
- Nome cadastrado
- E-mail cadastrado
- Data e hora do cadastro

Dica: Antes de avançar, pergunte à IA se faltou algum edge case. Requisitos incompletos geram testes incompletos.

Outra dica: Peça para um modelo de IA diferente do que você está usando revisar os requisitos e apontar falhas graves, contradições ou cenários não cobertos. Modelos diferentes cometem erros diferentes.

Prompt:

Faltou alguma coisa importante que não considerei? Algum edge case?

Passo 2: Visualizar o fluxo

Com os requisitos prontos, gere um fluxograma para validar o entendimento antes de escrever código.

Prompt:

Com base no arquivo .md criado, crie um fluxograma
da esquerda para a direita exemplificando o fluxo.

Resultado:

Por que isso importa? O fluxograma torna visível a ordem das validações e os caminhos de erro. É mais fácil revisar um diagrama com o time do que revisar código.

Passo 3: Criar a classe sem implementação (RED)

Crie apenas o esqueleto da classe, com as dependências e a assinatura do método, sem nenhuma lógica. O método deve lançar NotImplementedException.

Prompt:

Crie a classe de Caso de Uso sem implementação alguma no método,
apenas com as dependências possíveis com base nos requisitos.

Resultado:

public class CreateUserUseCase
{
    private readonly IUserReadRepository _readRepository;
    private readonly IUserWriteRepository _writeRepository;
    private readonly IPasswordHasher _passwordHasher;

    public CreateUserUseCase(
        IUserReadRepository readRepository,
        IUserWriteRepository writeRepository,
        IPasswordHasher passwordHasher)
    {
        _readRepository = readRepository;
        _writeRepository = writeRepository;
        _passwordHasher = passwordHasher;
    }

    public Task<Result<CreateUserResponse>> ExecuteAsync(CreateUserCommand command)
    {
        throw new NotImplementedException("Implementação pendente");
    }
}

Passo 4: Escrever os testes (RED)

Com a classe vazia criada, peça à IA para escrever os testes baseando-se nos requisitos. Os testes devem falhar neste momento, isso é esperado e correto.

Uma observação sobre o ritmo: no TDD clássico, o ciclo é executado um teste por vez: escreve um teste, faz passar, refatora, repete. Aqui estamos escrevendo todos os testes de uma vez antes de implementar, o que é uma adaptação prática para trabalhar com IA.

Prompt:

Com base no arquivo de requisitos e nessa classe de caso de uso,
escreva os testes unitários que validem cada requisito seguindo o padrão Arrange-Act-Assert, e confirme que eles estão falhando.

Resultado: testes falhando:

Antes de avançar, verifique se a cobertura está completa.

Prompt:

Esses testes estão cobrindo totalmente os requisitos
ou faltou algum caso?

Regra de ouro do TDD: só avance para o GREEN depois que todos os testes estiverem escritos e falhando pelo motivo certo: NotImplementedException, não erro de compilação.

Passo 5: Fechar o agente e abrir uma nova sessão

Antes de implementar, feche o agente completamente e abra uma nova conversa ou limpe o contexto do agente, por exemplo com /clean.

Na fase GREEN, a única fonte da verdade é o teste. Não o requisito, não o fluxograma, não a conversa anterior.

Passo 6: Implementar para passar nos testes (GREEN)

Na nova sessão, mostre apenas os testes e a classe vazia. O objetivo aqui é apenas fazer os testes passarem, sem se preocupar com qualidade, padrões ou boas práticas ainda.

Prompt:

Com base nos testes unitários existentes para a criação de usuário,
crie a implementação do caso de uso.

Resultado: testes passando:

Importante: nesta fase é normal o código ficar feio. Validações inline, strings hardcoded, acoplamentos diretos, tudo isso é esperado. O que importa é: os testes passam.

Passo 7: Identificar os problemas (REFACTOR)

Com os testes verdes, peça à IA para revisar o código com olhar crítico.

Pergunte o que está errado, não se está certo. Modelos de IA tendem a confirmar o que o usuário quer ouvir. "O código está bom?" quase sempre recebe um "sim". "Quais são os problemas?" força uma análise real.

Prompt:

Liste os problemas encontrados no código implementado
com base nas boas práticas de desenvolvimento.

Resultado:

Passo 8: Refatorar (REFACTOR)

Com a lista de problemas em mãos, peça à IA para corrigi-los. Os testes são a rede de segurança: se alguma refatoração quebrar o comportamento, os testes vão acusar imediatamente.

Refatorar é mudar como, não o quê. O comportamento externo deve permanecer idêntico antes e depois. Se um teste quebra durante a refatoração, significa que ele estava testando um detalhe interno de implementação em vez do comportamento, e provavelmente precisa ser revisado junto com o código.

Prompt:

Refatore esses pontos de melhoria no código.

Resultado:

Os problemas encontrados foram violações de SRP (uma classe deve ter apenas uma responsabilidade), OCP (aberto para extensão, fechado para modificação), ISP (interfaces não devem forçar dependências desnecessárias), DIP (dependa de abstrações, não de implementações concretas), DRY (não repita a mesma lógica em lugares diferentes) e um problema de segurança com salt fixo na senha.

Passo 9: Confirmar que tudo ainda passa

Após a refatoração, rode os testes novamente para garantir que nenhum comportamento foi quebrado.

Prompt:

Execute novamente todos os testes.

Resultado: 24/24 passando:

Passo 10: Testar manualmente e em homologação

Com os testes automatizados passando, valide o comportamento real da feature em ambiente de homologação ou por meio de testes manuais. Ferramentas e integrações que os testes unitários não cobrem só aparecem aqui.

Se algo der errado, não tente corrigir diretamente no código. Volte ao Passo 1 e trate o bug como uma nova demanda:

Descreva o comportamento incorreto como um requisito, o que deveria acontecer e o que está acontecendo, volte para o passo 1.

Por que isso importa? Um bug corrigido sem teste pode voltar sem que ninguém perceba. O teste que comprova o bug é a garantia de que ele nunca mais vai passar despercebido.

Conclusão

O ciclo completo ficou assim:

Requisitos → Fluxograma → Esqueleto → Testes falhando
→ Fechar agente → Implementação passando → Refatoração → Testes passando

TDD com IA significa usar o agente de IA para acelerar cada etapa do ciclo enquanto você, desenvolvedor, mantém o controle das decisões importantes: o que o sistema deve fazer, quais casos precisam ser testados e quando o código está bom o suficiente para ir para produção.

TDD Is No Longer Optional in the World of AI Agents

André N. Darcie — Mon, 16 Mar 2026 19:00:54 +0000

Test-Driven Development (TDD) is a development practice where you write tests before writing the code. The cycle is simple: write a failing test, implement the minimum code to make it pass, refactor. Repeated in a loop, this ensures the code does exactly what was specified.

A lot of people use AI like this: send the finished class and ask it to generate tests.

The problem is that the model is just completing a token puzzle. It generates tests that match the existing code, not necessarily the correct behavior.

For the model, it's not really understanding the system. It's just trying to predict the next likely token. So the test ends up being just a logical continuation of the code.

Inverting the process

What worked for me was inverting this using TDD.

The agent reads the functional requirements.
The agent generates tests based on those requirements.
I clear the context (new agent, blank context).
I ask it to implement the code that makes the tests pass.

At this point the agent has only one clear goal: make the tests pass.

It tries, fails, tries again, in a loop, until it succeeds.

Why this works

This works because tests are deterministic. For the same code, the result will always be the same.

Agents are not deterministic. There is randomness, there is hallucination, and we don't have full control over what the model will generate.

So everything we can build to contain that behavior helps.

Tests end up being exactly that: a kind of cage to control the chaotic behavior of agents.

Bugs too

I've used this approach in critical projects where bugs simply weren't an option. The flow was: first have the agent create a test that actually breaks and reproduces the problem. Only then ask it to fix it.

Because if you just ask the AI to "fix the bug," it might simply invent a solution and claim it worked.

But tests don't lie.

Tests create a forced feedback loop.

A good practice that became mandatory

In the world of AI agents, TDD has gone from being an optional good practice to being practically mandatory.

With AI-generated code, we saw a boom in automated tests. That made a big difference: code without tests lost value, because generating tests no longer costs anything. But we can go a level higher. Instead of generating tests for code, we generate tests for requirements. That's TDD, and it's the next step.

Qwen3.5 rodando localmente: super rápido e com ótima qualidade

André N. Darcie — Sun, 08 Mar 2026 15:11:31 +0000

Testei o Qwen3.5 rodando localmente e fiquei impressionado.

Resolvi testar o novo modelo open source Qwen3.5 no meu notebook, sem muita pretensão. A ideia era só ver como ele se comportava rodando localmente.

O que aconteceu me surpreendeu bastante: ele é brutalmente rápido.

As respostas vinham tão rápidas e tão boas que em um momento eu parei e fui conferir se aquilo realmente estava rodando em localhost ou se, por algum motivo, estava chamando alguma API externa. Mas não. Era tudo local mesmo.

Exemplo:

LLM local

O Qwen3.5-9B é desenvolvido pela Alibaba e tem 9 bilhões de parâmetros. Suporta 256K tokens de contexto e 201 idiomas.

Uma IA rodando 100% offline no notebook, sem API, sem custo e sem enviar dados para lugar nenhum.

Hardware

RTX 3060 Laptop (6GB VRAM)
16GB RAM
Windows 11

Stack

Modelo: Qwen3.5-9B UD-Q4_K_XL (Unsloth Dynamic 4-bit)
Runtime: llama.cpp com CUDA
Interface: llama-server com web UI em localhost:8080

Performance

A performance ficou em torno de 45 tokens por segundo, rodando completamente na GPU.

Para um notebook, isso é impressionante.

Instalação

Segui o guia oficial da Unsloth para rodar o modelo:

https://unsloth.ai/docs/models/qwen3.5

Foi bem direto de configurar.

Impressão geral

A sensação é que LLMs locais realmente estão chegando em um nível muito prático de uso. Rodar um modelo desse porte offline, no próprio notebook, com essa velocidade e qualidade de resposta, é algo que até pouco tempo atrás parecia distante.

E agora está simplesmente rodando em localhost.

A IA fez o trabalho de vários membros da minha equipe, e isso vai gerar demissões

André N. Darcie — Fri, 13 Feb 2026 12:25:03 +0000

A lógica é simples: se uma IA poderosa operada por 1 pessoa substitui a produtividade de uma equipe de 10, então podemos demitir 9 e está tudo resolvido?

Não.

Seguindo essa mesma lógica, 10 pessoas usando IA produziriam como 100. E se o seu concorrente fizer isso enquanto você reduz equipe, você acabou de se colocar em desvantagem.

Ao demitir porque “a IA já entrega o mesmo que o time atual”, a empresa está presa à fotografia de hoje. Só que a régua mudou.

Uma concorrente que mantenha seus desenvolvedores e os potencialize com IA não apenas preserva a capacidade de entrega, mas amplia velocidade, qualidade e experimentação. Enquanto isso, a empresa que encolhe o time corre o risco de ver seu produto evoluir mais lentamente, tornar-se superficial e perder competitividade.

Gone Home: o jogo que destruiu as regras e construiu um novo sentido para videogames [PT-BR]

André N. Darcie — Thu, 01 May 2025 12:41:58 +0000

Introdução

Em 2013 joguei Gone Home, há mais de dez anos, e ele mudou completamente o que eu achava que um videogame poderia ser. Destruiu minhas crenças. Me obrigou a encarar uma epifania tão bruta e desconfortável que levou mais de uma década para eu começar a digerir.

Jogo

Quando penso em "jogo" no sentido mais puro e essencial, fora do digital, penso em um conjunto claro de regras que definem vencedores e perdedores, como no futebol, vôlei, golfe ou pôquer. O primeiro sucesso digital foi Pong (1972), lançado em 1972 pela Atari: basicamente um "tênis de mesa" virtual, dois jogadores controlam raquetes verticais e devem rebater uma bola em linha reta; deixar passar é ponto para o oponente. Depois vieram níveis, fases, mais desafio e ação com Space Invaders (1978), puzzles com Tetris (1984) e power-ups em Pac-Man (1980). Em Super Mario Bros. (1985), a essência é atravessar plataformas e vencer obstáculos; em The Legend of Zelda (1986), explorar, pegar itens e derrotar inimigos; em Metal Gear Solid (1998), mais cinematográfico, infiltrar-se em bases evitando ser detectado. Em todos esses casos, não importa a história, os gráficos ou a tecnologia: o núcleo sempre foi o mesmo — regras claras, objetivos definidos, ação estruturada em vencer, avançar, sobreviver ou resolver.

Quando comecei Gone Home, achei que fosse um jogo de terror: casa grande, chuva, noite, ambientes escuros, pequenos puzzles. Esperei um susto — nada aconteceu. Controle em primeira pessoa, mas sem voz, inventário, níveis, árvore de habilidades, barra de vida. Só olhos. E do outro lado? Nada. Sem inimigos. Sem puzzles de verdade. Sem correr contra o relógio. Sem armas. Sem habilidades. Você é apenas uma pessoa comum, em uma casa comum e vazia. Não existe aventura. Só exploração livre e reconstrução da história a partir do ambiente, sem diálogos, sem personagens interativos, sem missões.

Influência

Gone Home rasgou o modelo tradicional de "ação e objetivo" e focou 100% em exploração e narrativa ambiental, algo praticamente inexistente na época. Embora Dear Esther já tivesse dado os primeiros passos nesse formato, foi Gone Home que consolidou e popularizou o gênero, provando seu potencial comercial e crítico. Mostrou que jogos podem contar histórias emocionais profundas — sobre família, sexualidade, aceitação — sem combate, sem missão, sem desafio, sem sequer levantar uma arma ou marcar pontos. Foi um dos marcos na criação do que hoje chamam de "walking simulator", influenciando títulos como The Stanley Parable, Firewatch e What Remains of Edith Finch, entre outros. Também quebrou barreiras temáticas, trazendo discussões polêmicas para o centro, de forma madura..

O impacto foi tão grande que muita gente ficou perdida, sem saber se aquilo era mesmo um videogame. "Walking simulator" surgiu como termo pejorativo. E mesmo grandes estúdios, como a Naughty Dog, beberam dessa fonte, adicionando momentos mais contemplativos em Uncharted 4.

Eu cresci jogando videogame. Já sabia o que esperar: vencer, perder, marcar pontos, completar fases. Gone Home veio como um martelo. Destruiu esse conceito até sobrar uma folha em branco. Redefiniu para mim o que é videogame e o que ele pode ser.

isso não é jogo.
isso não é jogo.
isso não é jogo.

Gone Home foi pensado como uma ruptura proposital. Steve Gaynor e a Fullbright queriam uma narrativa íntima e emocional, sem inimigos, sem ação, focada em ambientação, inspirados por Minerva’s Den. O sucesso, somado à polêmica ("isso não é jogo"), consolidou Gone Home como o ponto zero dos walking simulators modernos, abrindo espaço para experiências focadas apenas em história e reflexão.

Não há vitória. Não há derrota. Tampouco um objetivo explícito a ser conquistado. A lógica tradicional do triunfo é abandonada: não se escolhe entre modos Fácil, Médio ou Difícil. Em seu lugar, resta apenas a experiência sensível — sentir, compreender, refletir — como únicos movimentos possíveis dentro da narrativa.

Gone Home foi essencial para a criação do Bitsy, ao mostrar a Adam Le Doux que a exploração de ambientes e a narrativa íntima poderiam ser o coração de uma experiência de jogo. Inspirado por essa abordagem, ele desenvolveu o Bitsy como uma ferramenta voltada para a criação de pequenos mundos e histórias pessoais. Apesar de sua simplicidade e minimalismo, o Bitsy conquistou um espaço de destaque no cenário mundial de desenvolvimento de jogos e, no Itch.io — a maior plataforma de jogos independentes — figura entre as 10 engines mais utilizadas, ao lado de gigantes como Unreal Engine, RPG Maker, Game Maker e Unity.

História

Em Gone Home, você é Katie, uma jovem que retorna para casa depois de um ano viajando e encontra tudo vazio, ecoando ausências. Ao explorar cada canto, você descobre que sua irmã, Sam, viveu um romance secreto com outra garota, enfrentou a rejeição da família e, no fim, fugiu para viver esse amor.

É estranho? Incomum? É cru, vulnerável. Um nível de exposição emocional que nem Hollywood costuma ter coragem de tocar, muito menos os games tradicionais. Aqui não há heróis salvando princesas, cientistas resolvendo catástrofes ou soldados combatendo terroristas. Existe apenas a vida real, com toda sua dor, desejo e imperfeição. É íntimo, é humano. Parece mais uma delicada história francesa, sussurrada, profunda.

O valor das experências

Além da ruptura estrutural, Gone Home também foi alvo de críticas pela sua curta duração. Muitos jogadores questionaram pagar preço cheio por uma experiência que, para a maioria, dura entre uma e duas horas. Isso abriu um debate que se estenderia para outros jogos focados em narrativa: o valor de um jogo deveria ser medido pela quantidade de horas, pela profundidade da experiência, ou por outro critério? A polêmica expôs o quanto a indústria e o público ainda estavam presos à ideia de que tempo de jogo é equivalente a valor.

Comparação com a indústria

Se você olha para as maiores franquias — Mario, Tetris, Call of Duty, Pokémon, GTA, Minecraft, FIFA — todas giram em torno da mesma base: regras claras, objetivos definidos, recompensa constante. Jogar para vencer. Jogar para progredir. Mesmo Minecraft, lembrado pelo modo criativo, ganha peso real no modo sobrevivência: construir, evoluir, proteger-se de monstros, resistir noite após noite.

Num mundo onde Call of Duty é gigante e Counter-Strike movimenta milhões de jogadores na Steam, imaginar um jogo pacífico, explorativo, onde nem a sua história é vivida — apenas se descobre a história dos outros, lendo papéis e diários abandonados — soa quase absurdo. Não há herói. Só um observador.

Myst (1993) construiu um mundo sem textos ou inimigos, focado em exploração e resolução intensa de puzzles como principal forma de narrativa. System Shock (1994) usou gravações de áudio e cenários destruídos para reconstruir uma catástrofe. Half-Life (1998) eliminou cutscenes e obrigou o jogador a presenciar os eventos dentro do próprio cenário. Deus Ex (2000) espalhou fragmentos de história em documentos, diálogos e espaços físicos, ligando narrativa a exploração e escolhas. BioShock (2007) transformou Rapture numa cidade-personagem, onde cada ruína, cada grafite e cada gravação reforçavam a falência de uma utopia. Dark Souls (2011) escondeu todo seu enredo em fragmentos do mundo e nas descrições de itens, exigindo do jogador leitura ativa do ambiente. Mas quase todos ainda dependiam de combate, vitória, progressão — até que Gone Home (2013) rompeu totalmente: nada de combate ou mecânicas profundas de gameplay. Só narrativa ambiental pura.

Todos esses jogos são fantásticos e têm seus méritos. Mas Gone Home rompeu com tudo isso — e provou que, sim, existe espaço para algo realmente diferente.

Conclusão

Gone Home não foi só um jogo, foi um manifesto silencioso que desafiou os alicerces da indústria ao trocar ação por introspecção, desafio por contemplação, e vitória por empatia; ao abandonar as regras tradicionais que definem um jogo, ele não apenas abriu caminho para um novo gênero, mas escancarou a possibilidade de que experiências interativas podem ser também íntimas, humanas e profundamente emocionais — sem precisar das mecânicas e gameplay tradicional.

Profundos agradecimentos aos meus amigos que ajudaram a revisar o texto e a melhorá-lo de forma espetacular: Adriel, Danilo, Diguifi, Drão, Geovani e Jean — listados aqui em ordem alfabética.

Entenda DDD de uma vez por todas, na implementação [PT-BR]

André N. Darcie — Fri, 21 Feb 2025 17:25:13 +0000

Introdução

O Domain-Driven Design (DDD), conforme definido no livro original Domain-Driven Design: Tackling Complexity in the Heart of Software, de Eric Evans, é uma abordagem para o desenvolvimento de software focada na modelagem do domínio central do negócio. Este post mostra uma implementação fiel aos conceitos do livro em um projeto de pagamentos usando C#.

O que o DDD é

✅ Modelagem focada no domínio do negócio.
✅ Comunicação clara entre desenvolvedores e especialistas do domínio.
✅ Uso da Linguagem Onipresente (Ubiquitous Language).
✅ Separação clara de responsabilidades.
✅ Regras de negócio encapsuladas no domínio.
✅ Limites explícitos entre diferentes contextos (Bounded Contexts).

O que o DDD não é

❌ Não é necessário para sistemas simples.
❌ Não é sobre focar em detalhes técnicos.
❌ Não é apenas uma divisão em camadas.
❌ Não é obrigatório usar repositórios ou serviços para tudo.
❌ Não é uma metodologia rígida, mas uma abordagem de design.

1. Conceitos Fundamentais do DDD

Bounded Contexts: Define o limite explícito de cada parte do sistema, garantindo que cada contexto tenha seu próprio modelo e linguagem.
Entidades: Representam objetos com identidade única.
Value Objects: Representam conceitos do domínio sem identidade própria.
Agregados: Conjunto de entidades e objetos de valor que devem ser tratados como uma unidade.
Repositórios: Fornecem um acesso controlado aos agregados.
Serviços de Domínio: Contêm operações que não pertencem a uma única entidade.
Fábricas: Simplificam a criação de objetos complexos.

1.1 Linguagem Onipresente (Ubiquitous Language)

Antes de ir para a implementação, é essencial definir a Linguagem Onipresente para garantir uma comunicação clara entre desenvolvedores e especialistas do domínio. No sistema de pagamentos, que vamos implementar apresenta conceitos como Pedido de Pagamento (conjunto de pagamentos de um cliente), Pagamento (transferência de valor) e Método de Pagamento (forma de pagamento, como "Cartão de Crédito" ou "PIX") são usados diretamente nas classes PedidoDePagamento, Pagamento e MetodoPagamento.

Para isso, os desenvolvedores devem colaborar com equipes como o Comercial, para entender os tipos de transações e métodos de pagamento aceitos; o Financeiro, para garantir que as regras de cálculo e validação dos valores estejam corretas; e o Atendimento ao Cliente, para alinhar mensagens de erro claras, como "O valor do pagamento deve ser maior que zero". Essa colaboração garante que o sistema reflita a realidade do negócio.

1.2 DDD Não é Sobre Arquitetura, é Sobre o Domínio

Embora o DDD influencie a estrutura do código, ele não é sobre arquitetura, mas sim sobre compreender e modelar o domínio do negócio. Seu foco principal é capturar a lógica e os processos do domínio de forma clara e coesa, garantindo que o software reflita as necessidades da empresa. A arquitetura é apenas um meio de implementar esses conceitos, mas o verdadeiro valor do DDD está em alinhar a linguagem e o modelo do sistema com a realidade do negócio.

1.3 Mapa de Contexto (Context Map)

O Mapa de Contexto é uma ferramenta essencial no DDD, utilizada para visualizar como os diferentes Bounded Contexts interagem entre si. Ele define as relações, dependências e formas de comunicação entre os contextos, garantindo que o sistema mantenha a coesão e a integridade do domínio.

No sistema de pagamentos, por exemplo, o contexto de Pedidos de Pagamento poderia se relacionar com o contexto de Gestão Financeira para validar transações e gerar relatórios, enquanto o contexto de Atendimento ao Cliente acessa informações de pedidos para prestar suporte. Essas interações devem ser documentadas em um Mapa de Contexto, utilizando termos da Linguagem Onipresente, facilitando a comunicação entre equipes e garantindo que o design do sistema esteja alinhado às operações do negócio.

Para este exemplo, focaremos apenas no contexto de Pedidos de Pagamento para simplificar a implementação e destacar os principais conceitos do DDD sem a complexidade das interações entre múltiplos contextos. Essa abordagem facilita o entendimento inicial, permitindo aprofundar-se em mapas de contexto em cenários mais avançados.

1.4 Simplicidade e Clareza

Por fim, o DDD valoriza a simplicidade e a clareza do domínio, evitando abstrações desnecessárias e focando no que realmente importa para o negócio. No contexto de Pedidos de Pagamento, isso significa usar uma estrutura direta, com poucas camadas e apenas os componentes necessários para manter o domínio coeso. Repositórios, fábricas e serviços devem ser utilizados apenas quando agregam valor ao design.

2. Implementação

2.0 Entidade `Pagamento`

A classe Pagamento é uma entidade que possui um identificador único (Id), o qual garante sua distinção dentro do agregado. O construtor da entidade assegura a consistência do domínio ao exigir um valor positivo e um objeto válido do Value Object MetodoPagamento, evitando a criação de objetos em estado inválido. A propriedade Valor representa o montante da transação, enquanto a propriedade Metodo incorpora o Value Object que descreve o método de pagamento utilizado. Como parte do agregado PedidoDePagamento, a entidade Pagamento não pode existir fora do contexto desse agregado, garantindo que todas as operações relacionadas ao seu ciclo de vida sejam controladas pelo Aggregate Root.

public class Pagamento
{
    public Guid Id { get; private set; }
    public decimal Valor { get; private set; }
    public MetodoPagamento Metodo { get; private set; }

    internal Pagamento(decimal valor, MetodoPagamento metodo)
    {
        if (valor <= 0)
            throw new ArgumentException("O valor do pagamento deve ser maior que zero.");

        Id = Guid.NewGuid();
        Valor = valor;
        Metodo = metodo ?? throw new ArgumentNullException(nameof(metodo));
    }
}

2.1 Entidade `PedidoDePagamento`

A classe PedidoDePagamento é um Aggregate Root que possui um identificador único (Id), controla a adição de objetos do tipo Pagamento através do método AdicionarPagamento, e expõe apenas uma coleção de leitura (IReadOnlyCollection), garantindo que os pagamentos só possam ser modificados dentro do próprio agregado, mantendo a integridade do domínio.

public class PedidoDePagamento
{
    public Guid Id { get; private set; }
    private readonly List<Pagamento> _pagamentos;
    public IReadOnlyCollection<Pagamento> Pagamentos => _pagamentos.AsReadOnly();

    internal PedidoDePagamento()
    {
        Id = Guid.NewGuid();
        _pagamentos = new List<Pagamento>();
    }

    internal void AdicionarPagamento(decimal valor, MetodoPagamento metodo)
    {
        var pagamento = new Pagamento(valor, metodo);
        _pagamentos.Add(pagamento);
    }
}

2.2 Value Object `MetodoPagamento`

A classe MetodoPagamento é um Value Object, não possui um identificador único, sendo caracterizada pelo valor da propriedade Nome, cuja imutabilidade é garantida pelo modificador somente leitura (get). Sua consistência é assegurada pelo construtor, que impede a criação de objetos com valores nulos ou em branco, garantindo que o objeto esteja sempre em um estado válido. Além disso, a classe existe apenas para descrever o meio de pagamento dentro de um contexto maior, como o agregado PedidoDePagamento, evidenciando que seu valor é mais relevante do que sua identidade.

public sealed class MetodoPagamento
{
    public string Nome { get; }

    public MetodoPagamento(string nome)
    {
        Nome = string.IsNullOrWhiteSpace(nome) 
            ? throw new ArgumentNullException(nameof(nome), "Método de pagamento não pode ser nulo ou vazio.")
            : nome;
    }
}

2.3 Fábrica `PedidoDePagamentoFactory`

Obs: Segundo o DDD, as fábricas são necessárias apenas para a criação de objetos complexos. Como PedidoDePagamento não é tão complexo, a fábrica pode ser dispensada, adicionei apenas como exemplo.

A classe PedidoDePagamentoFactory é uma Factory expõe o método estático CriarPedidoDePagamento, que simplifica o processo de criação de um PedidoDePagamento ao inicializar a entidade com um pagamento já adicionado. Esse método garante que o objeto seja criado em um estado válido, utilizando a classe MetodoPagamento para validar o nome do método de pagamento, promovendo a coesão e ocultando detalhes de implementação do processo de construção.

public static class PedidoDePagamentoFactory
{
    public static PedidoDePagamento CriarPedidoDePagamento(decimal valor, string metodo)
    {
        var pedido = new PedidoDePagamento();
        pedido.AdicionarPagamento(valor, new MetodoPagamento(metodo));
        return pedido;
    }
}

2.4 Repositório `IPedidoDePagamentoRepository`

O Repositório é um padrão utilizado para abstrair o acesso aos dados, fornecendo uma interface que permite recuperar e armazenar objetos de domínio sem expor os detalhes da infraestrutura. A interface IPedidoDePagamentoRepository é um repositório que define o contrato para a persistência da entidade PedidoDePagamento, garantindo que o domínio permaneça independente da tecnologia de armazenamento. O método Adicionar permite incluir um novo pedido no repositório, enquanto o método ObterPorId possibilita a recuperação de um pedido existente a partir do seu identificador único (Guid), assegurando o encapsulamento do acesso aos dados e mantendo a coesão do domínio.

public interface IPedidoDePagamentoRepository
{
    void Adicionar(PedidoDePagamento pedido);
    PedidoDePagamento ObterPorId(Guid id);
}

2.5 Serviço de Domínio `ProcessadorDePedido`

Obs: segundo o DDD, o serviço de domínio deve conter lógica que não pode ser atribuída a nenhuma entidade. Se o ProcessadorDePedido apenas delega para a fábrica e repositório, pode ser desnecessário, adicionei apenas como parte do exemplo, assim como a Factory.

A classe ProcessadorDePedido é um serviço de domínio que coordena o processo de criação e persistência de um PedidoDePagamento, sem violar o princípio de responsabilidade única. Ela recebe uma instância de IPedidoDePagamentoRepository via injeção de dependência, promovendo a desacoplagem entre o domínio e a infraestrutura de dados. O método Processar utiliza a Factory PedidoDePagamentoFactory para garantir a criação consistente do pedido, e em seguida delega ao repositório a responsabilidade de armazená-lo.

public class ProcessadorDePedido
{
    private readonly IPedidoDePagamentoRepository _repository;

    public ProcessadorDePedido(IPedidoDePagamentoRepository repository)
    {
        _repository = repository;
    }

    public void Processar(decimal valor, string metodo)
    {
        var pedido = PedidoDePagamentoFactory.CriarPedidoDePagamento(valor, metodo);
        _repository.Adicionar(pedido);
    }
}

2.6 DbContext `PagamentosDbContext`

A classe PagamentosDbContext define os conjuntos de dados para as entidades PedidoDePagamento e Pagamento, permitindo operações de leitura e gravação no banco. O método OnModelCreating garante o mapeamento correto das entidades, definindo as chaves primárias com o método HasKey, assegurando a integridade dos dados no nível do banco. O Value Object MetodoPagamento é configurado como um Owned Type, de acordo com os princípios do DDD, garantindo que ele não possua uma tabela própria, mas seja armazenado junto à entidade Pagamento. Além disso, o construtor recebe as opções de configuração necessárias, promovendo a flexibilidade e a integração com diferentes provedores de banco de dados, enquanto mantém o domínio desacoplado da infraestrutura.

public class PagamentosDbContext : DbContext
{
    public PagamentosDbContext(DbContextOptions<PagamentosDbContext> options) : base(options) {}

    public DbSet<PedidoDePagamento> PedidosDePagamento { get; set; }
    public DbSet<Pagamento> Pagamentos { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<PedidoDePagamento>().HasKey(p => p.Id);
        modelBuilder.Entity<Pagamento>().HasKey(p => p.Id);

        modelBuilder.Entity<Pagamento>().OwnsOne(p => p.Metodo, metodo =>
        {
            metodo.Property(m => m.Nome)
                .IsRequired()
                .HasMaxLength(100)
                .HasColumnName("MetodoPagamentoNome");
        });

        base.OnModelCreating(modelBuilder);
    }
}

2.7 Repositório Concreto `PedidoDePagamentoRepository`

A classe PedidoDePagamentoRepository é uma implementação concreta da interface IPedidoDePagamentoRepository, utilizando o PagamentosDbContext para realizar as operações de acesso ao banco de dados. O método Adicionar insere uma nova instância de PedidoDePagamento no contexto e salva as alterações no banco de dados através do método SaveChanges, garantindo a persistência imediata. O método ObterPorId busca uma instância de PedidoDePagamento com base no identificador único (Guid), utilizando o método Include para carregar a coleção de pagamentos associados, assegurando que o agregado seja recuperado em sua totalidade, conforme o princípio da consistência transacional do DDD. Dessa forma, o repositório mantém a integridade do domínio ao isolar os detalhes da persistência, promovendo um código mais limpo e coeso.

public class PedidoDePagamentoRepository : IPedidoDePagamentoRepository
{
    private readonly PagamentosDbContext _context;

    public PedidoDePagamentoRepository(PagamentosDbContext context)
    {
        _context = context;
    }

    public void Adicionar(PedidoDePagamento pedido)
    {
        _context.PedidosDePagamento.Add(pedido);
        _context.SaveChanges();
    }

    public PedidoDePagamento ObterPorId(Guid id)
    {
        return _context.PedidosDePagamento.Include(p => p.Pagamentos).FirstOrDefault(p => p.Id == id);
    }
}

3. Estutura final da implementação

A camada Domain representa o núcleo do negócio, contendo as entidades Pagamento e PedidoDePagamento, o Value Object MetodoPagamento, a interface do repositório IPedidoDePagamentoRepository, o serviço de domínio ProcessadorDePedido e a fábrica PedidoDePagamentoFactory para a criação consistente dos agregados. Já a camada Infrastructure implementa os detalhes técnicos de persistência dos dados usando o EF Core, com o contexto PagamentosDbContext para configurar o banco de dados e o repositório concreto PedidoDePagamentoRepository, que realiza a interação com o banco seguindo o contrato definido na camada de domínio. Essa organização garante um sistema modular, coeso e de fácil manutenção, com o domínio livre de dependências externas.

PagamentoProjeto
│
├── PagamentoContext
│   ├── Domain
│   │   ├── Aggregates
│   │   │   ├── PedidoDePagamento
│   │   │   │   ├── PedidoDePagamento.cs
│   │   │   │   ├── Pagamento.cs
│   │   │   │   └── ValueObjects
│   │   │   │       └── MetodoPagamento.cs
│   │   ├── Factories
│   │   │   └── PedidoDePagamentoFactory.cs
│   │   ├── Repositories
│   │   │   └── IPedidoDePagamentoRepository.cs
│   │   └── Services
│   │       └── ProcessadorDePedido.cs
│   │
│   └── Infrastructure
│       ├── Data
│       │   ├── Context
│       │   │   └── PagamentosDbContext.cs
│       │   └── Repositories
│       │       └── PedidoDePagamentoRepository.cs

3. O Que Não Foi Utilizado do DDD Nesta Implementação

Essa implementação optou por não utilizar alguns elementos que, embora recomendados, não eram essenciais para o exemplo apresentado. Não foram aplicados os conceitos de Domínio Rico (Rich Domain) em sua plenitude, nem o uso extensivo de Domain Events, que são úteis para notificar outras partes do sistema sobre mudanças no domínio. A camada de Application Services, que poderia coordenar a interação entre o domínio e a interface do usuário, também foi omitida para manter a simplicidade. Além disso, não foi abordado o uso de Anti-Corruption Layers para integração com sistemas externos, nem o padrão Specification, que ajuda a encapsular regras de negócio reutilizáveis. Essas ausências, no entanto, não comprometem o entendimento dos fundamentos do DDD, pois o foco do post foi demonstrar a aplicação prática dos elementos mais essenciais da abordagem.

4. Conclusão

Em suma, esta implementação exemplifica de forma clara e prática como aplicar os princípios do Domain-Driven Design (DDD) conforme definidos no livro original de Eric Evans. A organização modular do código, com entidades, Value Objects, agregados, repositórios e serviços de domínio, demonstra como esses componentes colaboram para manter a integridade do domínio e a coesão do sistema. Além disso, a separação entre as camadas de domínio e infraestrutura garante um design desacoplado, facilitando a manutenção e evolução do projeto. Dessa forma, a abordagem apresentada mostra como o DDD pode contribuir para o desenvolvimento de sistemas mais robustos, compreensíveis e alinhados às necessidades do negócio.

Como modelar microserviços corretamente? [PT-BR]

André N. Darcie — Thu, 20 Feb 2025 11:06:26 +0000

Este post foi totalmente inspirado no livro Building Microservices de Sam Newman.

Introdução

Escrevi um post inicialmente sobre quando não usar microserviços, agora chegamos em um novo momento. Caso realmente faça sentido usar microserviços, como proceder? Como definir o que realmente faz sentido ser um microserviço? Qual parte do sistema deve ser isolada e se será apenas um ou vários para definir um fluxo de negócio de forma eficiente?

Como modelar microservices corretamente?

Modelar microservices não é apenas dividir uma aplicação monolítica em partes menores. É preciso definir boas fronteiras, garantir independência e criar uma arquitetura que realmente traga benefícios. Aqui estão alguns princípios essenciais:

Como fazer uma boa fronteira?

Uma boa fronteira de microserviço evita vazamento de informações, reduz dependências e melhora a escalabilidade. Para isso:

Esconder dados e informações: Cada microserviço deve expor apenas o necessário.
Coesão: Serviços devem ter um propósito claro e bem definido.
Acoplamento: Minimizar dependências entre serviços garante mais flexibilidade.
Coesão e Acoplamento juntos: Um serviço bem coeso e com baixo acoplamento resulta em alta modularidade, permitindo maior escalabilidade e facilidade de manutenção.

Tipos de acoplamento

Existem diferentes formas de acoplamento que podem surgir ao modelar microservices:

Domínio (Aceitável): O serviço depende dos conceitos do negócio, o que é natural e desejável.
Pass-through (Menos Aceitável): O serviço apenas encaminha chamadas sem lógica significativa, o que pode indicar uma falha na modelagem.
Common (Ruim): Compartilhamento de código ou dependências comuns, como duas aplicações usando o mesmo banco de dados, pode gerar forte acoplamento e dificultar mudanças. Por exemplo, se um serviço precisa alterar o esquema do banco, o outro pode ser impactado, prejudicando a independência.
Content (Péssimo): Dependência de estrutura de dados interna de outro serviço, resultando em alto acoplamento e fragilidade na arquitetura.

DDD e Microservices

O Domain-Driven Design (DDD) é um guia essencial para definir boas fronteiras e tornar os microservices mais independentes. Alguns conceitos-chave:

Linguagem Ubíqua: Um vocabulário comum entre times técnicos e de negócio, garantindo que todos compreendam os termos do domínio.
Aggregate: Um aggregate deve agrupar entidades e objetos de valor que são tratados como uma única unidade, garantindo consistência interna. A definição de um aggregate deve seguir as seguintes regras:
- As mudanças dentro do aggregate devem ser atômicas e consistentes.
- O acesso externo a entidades internas do aggregate deve ser mediado pelo aggregate root.
- Exemplo: Em um sistema de pedidos, o aggregate pode ser o Pedido, contendo itens, endereço de entrega e informações de pagamento. Qualquer alteração deve ser feita através do Pedido, garantindo integridade.
Bounded Context: Define limites claros entre diferentes domínios de um sistema. Para modelar um bounded context corretamente:
- Identifique os conceitos de negócio que pertencem ao mesmo contexto e separe-os daqueles que não têm relação direta.
- Evite dependências entre bounded contexts distintos para evitar acoplamento indesejado.
- Exemplo: Em um sistema de e-commerce, o contexto de "Pedidos" não deve depender do contexto de "Catálogo de Produtos", pois cada um possui regras específicas e independentes.

Por que DDD casa tão bem com microservices?

O DDD se encaixa perfeitamente com microservices porque:

Permite dividir o sistema em contextos bem definidos, facilitando a identificação das fronteiras dos microservices.
Reduz a complexidade ao encapsular lógica de negócio dentro de aggregates, garantindo consistência interna.
Facilita a comunicação entre times por meio da Linguagem Ubíqua, evitando mal-entendidos.
Ajuda a evitar acoplamento excessivo ao definir boundaries bem estabelecidas, permitindo que cada microservice evolua de forma independente.

Alternativas ao DDD

Embora DDD seja uma abordagem sólida, existem outras estratégias para modelar microservices:

Volatilidade: Separar serviços considerando a frequência de mudanças, isolando partes mais voláteis para evitar impactos em outros serviços.
Dados: Projetar microservices em torno da posse e acesso a dados, garantindo que cada serviço tenha seu próprio repositório.
Tecnologia: Definir serviços de acordo com a stack tecnológica, permitindo o uso da melhor tecnologia para cada caso.
Organização: Criar serviços alinhados com a estrutura das equipes (Conway’s Law), promovendo autonomia e agilidade.

Referências e Leituras Recomendadas

Para aprofundar seus conhecimentos sobre modelagem de microservices, recomendo as seguintes leituras:

Building Microservices - Sam Newman: Livro essencial sobre a arquitetura de microservices, que deu origem a ideia desse post, cobrindo desde a modelagem até a implementação e manutenção.
Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans: O livro original sobre DDD, explicando em profundidade os conceitos de agregados, bounded contexts e linguagem ubíqua.

Ao modelar microservices corretamente, evitamos armadilhas como dependências excessivas e serviços mal definidos, garantindo uma arquitetura escalável e sustentável. Como você tem modelado seus serviços?

Quando NÃO usar microserviços [PT-BR]

André N. Darcie — Sat, 15 Feb 2025 13:27:28 +0000

Microservices têm um preço. Esse preço é tempo, dinheiro, complexidade extra no desenvolvimento, latência entre serviços, manter consistência de dados, testes, monitoramento, segurança, logging distribuído, CI/CD mais complexo, organização e orquestração. O custo é alto e, na maioria dos casos, não compensa. Já passei muitas vezes pelo dilema de escolher a arquitetura certa para projetos de diferentes tamanhos e necessidades, e aprendi que microservices nem sempre são a melhor solução. Antes de entrar nessa, avalie se realmente precisa deles.

🆕 Seu produto é novo

No início do desenvolvimento, a única certeza é a mudança. Você ainda não sabe como os clientes vão usar o sistema — ou sequer se ele será usado. Mesmo contratos assinados não garantem adoção real. O foco deve ser construir um monólito enxuto (MVP), testar hipóteses rapidamente, entregar valor e adaptar-se conforme necessário. A complexidade de microservices só atrasa esse processo. A abordagem padrão para a maioria dos casos deveria ser monolítica.

👥 Sua empresa/equipe é pequena

Se até grandes empresas lidam com desafios na adoção de microservices, imagine startups e equipes pequenas. Sem um time grande e experiente para gerenciar a complexidade envolvida, você estará apenas adicionando problemas desnecessários. Microservices fazem sentido quando há múltiplas equipes trabalhando em partes independentes de um sistema de grande escala. Se esse não é seu caso, o monólito continua sendo a melhor escolha.

📈 Você não precisa de grande escala

Microservices fazem sentido quando há um altíssimo volume de dados e tráfego, necessidade real de escalar componentes de forma independente e horizontalmente, além de quando todas as otimizações possíveis em uma arquitetura monolítica já foram exploradas. Se seu sistema não enfrenta esse nível de demanda, adotar microservices será apenas um desperdício de tempo, esforço e recursos.

🛠️ Seu código está acoplado e desorganizado

Separar um código bagunçado em microservices não resolve nada. Pelo contrário, só espalha o problema em vários lugares, tornando tudo ainda mais difícil de manter. O que realmente melhora a organização do código são boas práticas como SOLID, separação em camadas e design modular. É perfeitamente possível ter um monólito bem estruturado, robusto, desacoplado e de fácil manutenção.

Conclusão

Depois de anos lidando com diferentes projetos, aprendi que microservices não são a resposta para tudo. Pelo contrário, na maioria dos casos, um monólito bem feito é a escolha mais simples, eficiente e sustentável. Já vi times gastarem tempo e dinheiro resolvendo problemas que só existiam porque decidiram adotar microservices cedo demais. Se seu sistema ainda não sofre com desafios reais de escala e independência entre equipes, minha recomendação é clara: vá de monólito, entregue valor rápido e evite dores de cabeça desnecessárias.

Para quem deseja se aprofundar no tema, recomendo a leitura do livro Criando Microsserviços: Projetando Sistemas com Componentes Menores e Mais Especializados, de Sam Newman. Essa obra me ajudou a refletir de forma crítica sobre microservices.

Me obriguei a assistir a 250 filmes clássicos do cinema, e aqui está o que aprendi. [PT-BR]

André N. Darcie — Fri, 17 Jan 2025 11:09:27 +0000

Introdução

Demorei um total de 10 anos para concluir a lista, pois assisti a outros filmes ao longo do caminho, além de lidar com o fato de que a lista não era fixa e mudou bastante ao longo dos anos. Além disso, houve períodos em que fiz longas pausas antes de retomar o projeto. Foi extremamente difícil manter o foco em uma meta tão longa e cumpri-la sem desistir no meio do caminho. Minha principal motivação foi o desejo de não passar pela vida sem entender pelo menos o básico sobre cinema.

A ideia da lista foi conhecer de maneira eficiente os clássicos do cinema, principalmente de Hollywood. Usei a lista da IMDB. O melhor dessa abordagem foi assistir aos filmes na ordem da lista, sem pular nenhum, sem deixar o gosto pessoal interferir ou permitir que pensamentos como "não é o meu tipo de filme" ou "não é do meu gosto" atrapalhassem. Superar esses preconceitos me permitiu conhecer obras-primas. Além disso, a lista visava sair do óbvio, evitando filmes viralizados nas redes sociais, de alta bilheteria, ou recomendados por amigos, e ignorando os trailers mais vistos do YouTube. Assim, pude explorar filmes antigos, já fora da mídia há muito tempo, aquele filmes longos em preto e branco, e viajar pela história do cinema.

Não vou entrar no merito de julgar a lista em si por enquanto, mas ela é provavelmente a lista mais popular, serviu bem como introdução e hoje conheço outras listas com seriam mais variadas e talvez mais justas.

Uma questão importante é que, neste texto, decidi não comentar ou citar todos os filmes individualmente por questões práticas, já que isso tornaria o texto muito longo. Procurei capturar a essência geral deles e resumi-la aqui.

Viagem

Assistir a um filme é emprestar nossos olhos para outras vidas, mesmo aquelas mais distantes da nossa realidade. Cada filme é uma janela para histórias contadas de perspectivas únicas, moldadas por épocas diferentes, diretores singulares e uma rica teia de influências culturais, artísticas e filosóficas.

São histórias grandiosas ou breves, ambientadas em mundos fantásticos ou em realidades profundamente íntimas. Algumas exploram universos inteiros, enquanto outras se concentram no microcosmo de uma vida, seja ela realista ou fruto da imaginação. O cinema, em sua essência, é uma viagem: uma oportunidade de experimentar realidades distantes da nossa, vivenciar sentimentos que nunca havíamos considerado, e enxergar o mundo sob prismas completamente novos, são como cápsulas do tempo, permitindo-nos entender como as pessoas pensavam, sentiam e se expressavam em diferentes períodos da história.

É uma lição de humildade e de expansão da consciência, para entender que minha vida é apenas uma bolha, que meus valores e minha forma de viver são apenas uma possibilidade entre as infinitas existentes, que aquilo em que acredito não deve ser imposto aos outros, e que devo aprender com outras experiências, realidades, formas de ver as coisas e maneiras de viver.

Senso Critico

Com o tempo, fui percebendo padrões, modelos mentais e as diferentes formas de construção de um roteiro, de contar uma história e de prender a atenção do espectador. É curioso identificar esses padrões: começar a assistir a um filme e já compreender a mensagem que ele deseja transmitir, antecipar como a narrativa provavelmente se desenvolverá e terminará. Isso torna cada vez mais difícil ser surpreendido ou encantado, mas, ao mesmo tempo, faz com que fique mais fácil reconhecer quando a história tem o ritmo adequado ou quando se arrasta, quando os personagens são bem desenvolvidos e quando outros são deixados de lado.

Valor de um clássico

Aprendi a reconhecer o verdadeiro valor de um filme clássico: é aquele que, de tão influente, acaba se tornando um molde para os filmes que vêm depois dele. Os clássicos servem como uma base sólida para a criação cinematográfica. Se você assistiu a poucos clássicos, pode acabar achando que filmes recentes são incrivelmente geniais, criativos e inovadores, quando, na verdade, muitos deles foram diretamente inspirados por esses grandes marcos do cinema. Por isso, é fundamental ter essa referência para compreender o que realmente é novo e disruptivo.

Filmes que ensinam filosofia

Os filmes compartilham a capacidade de abordar aspectos profundos da condição humana, explorando temas universais como amor, poder, moralidade, sacrifício, identidade, liberdade, justiça e propósito.

Apesar de suas diferenças em gêneros, épocas e estilos narrativos, cada um deles provoca reflexão, desafia percepções e me conectou a dilemas filosóficos e emocionais atemporais.

Conheci grandes diretores e suas obras primas

Gostaria de destacar os filmes que provavelmente não teria assistido dessa lista e dos quais aprendi muito.

Conheci o diretor japonês Akira Kurosawa, que realizou filmes como Seven Samurai, Rashomon, Ikiru, Ran, Yojimbo e High and Low. Seus filmes são extremamente influentes na cultura ocidental. Filmes como Seven Samurai influenciaram a criação do gênero western. Kurosawa explorou temas universais como moralidade, justiça e a natureza humana; em Rashomon, ele abordou múltiplas perspectivas sobre um mesmo fato. Além disso, ele criou grandes épicos com batalhas em grande escala, como em Ran.

O diretor russo Andrei Tarkovsky não apenas explora a fé e a arte em Andrei Rublev e os desejos e a natureza do conhecimento em Stalker; ele eleva o cinema ao reino do espiritual e do transcendente. Suas obras não oferecem respostas, mas nos convidam a contemplar perguntas que resistem ao tempo, desafiando a lógica e evocando o mistério da existência. Tarkovsky transforma cada cena em poesia visual, carregada de simbolismo e impregnada de silêncio, exigindo do espectador não apenas atenção, mas entrega.

O diretor sueco Ingmar Bergman aborda temas existenciais e psicológicos, explorando a condição humana e a complexidade das relações em filmes como O Sétimo Selo, que trata da mortalidade e da fé, e Persona, que investiga a identidade e a comunicação.

O Studio Ghibli abriu portas para mundos mágicos. Obras como My Neighbor Totoro, Spirited Away, Princess Mononoke, Howl's Moving Castle e Grave of the Fireflies me colocaram em mundos mágicos diferentes, transformando o cinema em uma janela para a fantasia. Grave of the Fireflies é um dos filmes mais tristes e chocantes que já vi, sendo um dos melhores sobre a Segunda Guerra Mundial na visão de crianças.

A genialidade de Charles Chaplin está em unir o cômico ao crítico. Em City Lights e Modern Times, sua comédia física transcende a palavra, abordando questões sociais com uma sensibilidade atemporal, revelando a beleza e a tragédia do humano.

Com Quentin Tarantino, aprendi a apreciar a arte do diálogo e a ousadia narrativa. Pulp Fiction, Reservoir Dogs, Kill Bill: Volume 1/2 e Inglourious Basterds são filmes com diálogos excelentes e inesquecíveis, com situações muito criativas. São filmes divertidos e provocadores. Ele se tornou um dos meus diretores favoritos, apesar de eu gostar mais dos filmes antigos, em que tudo era mais arriscado.

Stanley Kubrick foi uma lição sobre o poder do cinema como linguagem definitiva. 2001: A Space Odyssey e A Clockwork Orange expandem os limites do pensamento, confrontando temas como evolução, controle e caos. Suas obras são estudos sobre a condição humana em sua forma mais crua e universal.

Por fim, Clint Eastwood, com filmes como Unforgiven e Gran Torino, desconstrói o herói clássico e nos confronta com a redenção, o preconceito e a busca por sentido nos últimos capítulos da vida.

Contemplação

Ver um filme pode ser um ato de resistência contra a pressa do mundo moderno. Obras contemplativas como as de Andrei Tarkovsky ou Terrence Malick nos desafiam a desacelerar, a observar o que parece banal e encontrar beleza nele. São lembretes de que a vida, em sua essência, é feita de pequenos momentos, muitas vezes ignorados.

O valor dos criticos

Aprendi muito com a crítica cinematográfica. Ela vai muito além de decidir se um filme é apenas "bom" ou "ruim". A verdadeira crítica analisa a obra de todos os ângulos possíveis: suas influências, seus significados mais profundos, e como ela dialoga com outros filmes, livros ou movimentos culturais de sua época.

Eu não vivi uma vida cercada por uma vasta bagagem de leitura de clássicos ou por um profundo estudo de cinema, mas muitas pessoas na crítica fizeram exatamente isso. Graças a elas, podemos compreender que um filme não é uma criação isolada; ele é muitas vezes uma resposta a algo maior, como um livro, uma obra anterior ou até mesmo o contexto cultural em que foi produzido. Mesmo assistindo a um filme dez vezes, seria difícil perceber essas camadas sem a ajuda de quem se dedicou a desvendá-las.

Entender o contexto de uma obra é fundamental para quem busca uma apreciação mais profunda. Se você sente essa necessidade de compreender um filme em sua totalidade, é muito valioso ler e ouvir a opinião de diversos críticos. Essas pessoas dedicaram tempo e esforço para explorar nuances que, sozinhos, talvez nunca tivéssemos a oportunidade de perceber. A crítica, quando bem feita, não só amplia nossa visão sobre a obra, mas também nos ensina a ver o mundo com mais profundidade.

Durante minha jornada explorando os filmes da lista, acabei descobrindo canais no YouTube de críticos que enriqueceram ainda mais minha experiência. Entre eles, destaco Isabela Boscov, com sua análise sofisticada e envolvente; Meus 2 Centavos, que traz opiniões diretas e bem fundamentadas; PH Santos, com seu estilo acessível e reflexivo; Dalenogare Críticas, conhecido por seu olhar técnico e detalhista; e Entre Planos, que apresenta reflexões profundas sobre a linguagem cinematográfica e os temas explorados nos filmes. Esses criadores não apenas analisam filmes, mas também expandem a compreensão do cinema como arte e linguagem.

Conclusão

Assistir aos filmes da lista do IMDb acabou sendo uma das experiências mais transformadoras que já vivi. Comecei com a ideia de conhecer os clássicos do cinema de forma organizada, sem deixar o gosto pessoal atrapalhar, mas, no fim, isso virou algo muito maior. Foi como abrir uma porta para mundos, ideias e histórias que nunca teria explorado se seguisse só minhas preferências ou opiniões.

Ao encarar cada filme sem pular nenhum, mesmo aqueles que não pareciam “o meu tipo”, percebi o quanto eu estava limitando minha visão. Filmes que eu provavelmente ignoraria me trouxeram momentos incríveis de reflexão, emoção e aprendizado. O cinema deixou de ser só entretenimento pra virar uma verdadeira viagem no tempo, na cultura e nas ideias.

No meio disso tudo, também entendi que não dá pra assistir a um clássico sem saber o contexto dele. Descobrir críticas, ler análises e ouvir pessoas que dedicam a vida a estudar cinema me ajudou a ir muito além do óbvio. Entender o porquê de um filme ser considerado genial foi tão enriquecedor quanto assisti-lo.

Hoje, quando olho pra essa experiência, sinto que cresci muito. Não só conheci grandes obras, mas também ampliei minha forma de enxergar o mundo e a arte. Cada filme foi uma oportunidade de sair da minha bolha, de desacelerar e de me conectar com histórias que, de alguma forma, me transformaram. O cinema, pra mim, virou um espaço pra aprender, sentir e viver coisas que nem sabia que precisava.

O Futuro do Blazor

André N. Darcie — Mon, 09 Dec 2024 21:31:53 +0000

Hoje, dia 9 de dezembro de 2024, foi publicado um vídeo entrevistando e confrontando Daniel Roth, Principal Product Manager do ASP.NET. Ele foi bastante honesto e transparente em suas respostas, e as perguntas feitas foram pertinentes. Este vídeo foi uma resposta a outro conteúdo questionando se o Blazor foi abandonado pela Microsoft. Aqui está uma visão geral do que observei:

A Microsoft abandonou ou vai abandonar o Blazor?
Não. No último .NET Conf, houve menos destaque para o Blazor, mas isso aconteceu porque, no .NET 8, o Blazor se tornou uma plataforma full stack para Web UI, com suporte a renderização estática e o auto render mode, tornando-se bem completo. Agora, no .NET 9, tivemos apenas melhorias incrementais e algumas novidades, funcionando como um período de maturação para as mudanças da versão anterior.

O Blazor vai se tornar mainstream?
Não. Esse nunca foi o objetivo. A ideia é que o Blazor seja mais uma ferramenta no arsenal do ASP.NET, tornando-o um framework web ainda mais completo.

O Blazor vai competir com ReactJS?
Não. O objetivo do Blazor nunca foi competir com frameworks de SPA, como React, Angular ou Vue, nem com o ecossistema nativo de JavaScript. Ele é apenas uma alternativa para desenvolvedores que não têm tempo, recursos ou necessidade de entrar em um novo ecossistema como o do JavaScript, com suas ferramentas, frameworks e boas práticas. O Blazor permite que essas pessoas continuem dentro do ASP.NET. Agora, o Blazor possui o auto render mode, que pode decidir entre Blazor Server ou Blazor WebAssembly automaticamente. Isso melhora bastante a questão da performance, mas se você está realmente preocupado com performance, a recomendação do próprio Daniel Roth é usar React.

Para qual uso devo utilizar o Blazor?
O Blazor não é adequado para aplicações de alta performance que precisam atender milhões de usuários e dispositivos simultaneamente. Ele é projetado para ser uma ferramenta produtiva, prática e fácil para desenvolvedores .NET.

Por que a Microsoft não usa o Blazor amplamente?
O sucesso do Blazor depende da Microsoft utilizá-lo em seus produtos? Não. O Blazor foi criado para atender pequenas equipes, projetos específicos e soluções internas. A Microsoft utiliza o Blazor em projetos internos, como backoffices. Porém, em projetos grandes e voltados ao público geral, a empresa utiliza React, porque faz mais sentido devido ao grande número de programadores JavaScript que possuem.

Para que tipo de empresa o Blazor é útil, grande ou pequena?
O Blazor é útil tanto para empresas pequenas quanto grandes. Ele é ideal para equipes pequenas, com poucos recursos, tempo ou dinheiro, que já trabalham com C# e .NET e precisam de uma solução rápida para atender aos requisitos. Para equipes grandes, bem estruturadas, com tempo e um time especializado tanto em backend .NET quanto em frontend com React ou JavaScript nativo, o Blazor pode não fazer sentido.

Qual é o foco do Blazor?
O foco do Blazor é produtividade para desenvolvedores ASP.NET, e não otimizar a performance para suportar milhares de usuários simultâneos ou lidar com uma ampla variedade de dispositivos.

Qual será o foco do Blazor no futuro?
Atualmente, temos o Blazor WebAssembly e o Blazor Server. No entanto, o foco será mais no Blazor Server. Houve grandes melhorias na questão de reconexão, por exemplo, quando um circuito é desligado. Agora, o foco será na capacidade de manter o estado da aplicação. Hoje, quando o circuito é encerrado, o estado é perdido. Se o usuário estiver em um formulário por etapas e no meio do processo, ele perde tudo e volta ao início. A Microsoft quer solucionar esse problema.

Devo usar o Blazor?
Se o objetivo do Blazor se alinha às suas necessidades, ele é uma excelente ferramenta. Ele permite construir aplicações de qualidade de forma produtiva e eficiente.

Devo investir em uma carreira em Blazor?
Não. Se você pesquisar apenas vagas para desenvolvedores Blazor, encontrará poucas. Em contrapartida, há um número gigantesco de vagas para React. Isso não significa que o Blazor não vale a pena, mas que as empresas buscarão desenvolvedores .NET/ASP.NET. Portanto, sua carreira não deve ser focada apenas no Blazor, mas no ecossistema .NET como um todo, conhecendo todas as suas ferramentas e sendo flexível.

Conclusão
As dúvidas sobre o Blazor, seu futuro e propósito, surgem, em grande parte, da falta de entendimento de que cada ferramenta possui um propósito específico, com vantagens, desvantagens e um público-alvo. Antes de escolher uma ferramenta, é importante saber responder algumas perguntas-chave. O propósito do Blazor sempre foi claro: atender a um nicho de desenvolvedores e equipes que desejam produtividade no ecossistema ASP.NET para construir aplicações Web UI.

Minha conclusão ao conhecer os "Design Patterns" [PT-BR]

André N. Darcie — Thu, 25 Jul 2024 00:47:47 +0000

Introdução

Terminei de conhecer os famosos "Design Patterns", descritos originalmente no livro "Design Patterns: Elements of Reusable Object-Oriented Software", lançado em 1994 pelo "Gang of Four" (GoF), que é, de longe, um dos maiores clássicos da área da computação. Organizei com meus colegas um clube do livro para ler uma versão mais acessível, prática e modernizada desse livro, que faz mais sentido para um clube. Trata-se do "Dive Into DESIGN PATTERNS", do famoso site Refactoring.Guru.

Minha reflexão

Depois de conhecer todos os 22 design patterns, comecei a perceber como eles influenciaram o mundo do desenvolvimento em que vivo hoje. Seja em livros, publicações, artigos, palestras, bibliotecas, frameworks ou até no design de linguagens mais modernas, eu vejo que os design patterns estão, digamos, no inconsciente coletivo. Mesmo que eu não os use diretamente, já estou recebendo influências deles de alguma forma.

Eu percebo que os design patterns não são ciência de foguetes; não são tão avançados que eu nunca poderia criá-los sozinho. Na verdade, são soluções para problemas comuns no desenvolvimento que muitas pessoas usaram repetidamente e decidiram catalogar em um livro, dando-lhes nomes para facilitar a comunicação dessas soluções entre desenvolvedores.

Eles não são um conjunto de regras fixas nem "as melhores soluções" absolutas. Tanto é que muitos dos patterns têm anti-patterns associados, cada um com seus prós e contras. Quando eu uso muitos desses patterns em um projeto simples, isso pode levar a um excesso de complexidade desnecessária.

Eu vejo que o software está em constante mudança, e a ideia é identificar problemas comuns, distinguir partes que geralmente não mudam daquelas que podem mudar constantemente nas regras de negócio, e aplicar um pattern que facilite a manutenção. Isso melhora a comunicação entre desenvolvedores e evita a reinvenção da roda, utilizando boas soluções já existentes.

Ler sobre todos os patterns é também um exercício para eu entender como bons desenvolvedores pensam e resolvem problemas. Ao terminar o livro, começo a pensar de maneira mais estruturada, como se eu tivesse na mente várias soluções possíveis para um problema, com base no repertório que adquiri ao conhecer cada um deles, o que melhora a qualidade, legibilidade e manutenibilidade do meu código. Isso me permite me apoiar nos ombros de gigantes e passar a adotar uma forma de pensamento semelhante à deles.

Exemplos práticos

No .NET, que é o framework que utilizo no meu trabalho há muitos anos, encontrei várias implementações de Design Patterns. Organizando por ordem de listagem, o Factory Method e o Abstract Factory podem ser encontrados no DbProviderFactory do ADO.NET. O StringBuilder é um exemplo do padrão Builder, enquanto a interface ICloneable implementa o padrão Prototype. O HttpContext.Current do ASP.NET é uma implementação clássica do padrão Singleton.

O padrão Adapter pode ser visto em IEnumerable, e o System.Drawing abstrai a implementação gráfica utilizando o padrão Bridge. No Windows Forms, a classe Control aplica o padrão Composite (Object Tree), permitindo uma estrutura hierárquica de controles. O padrão Decorator é implementado nas várias classes derivadas de Stream, enquanto o WebClient serve como uma Facade simplificada para operações HTTP.

A classe String utiliza o padrão Flyweight (Cache) para otimizar o uso de memória, e o WebProxy é uma implementação de Proxy, controlando o acesso a serviços de rede. No ASP.NET, os Middlewares seguem o padrão Chain of Responsibility (Chain of Command). No WPF, a interface ICommand representa o padrão Command, enquanto System.Collections.IEnumerator é uma implementação do padrão Iterator.

O padrão Mediator é exemplificado pela classe Page no ASP.NET, que coordena a interação entre os controles de uma página. Controles como Forms.TextBox utilizam o padrão Memento (Snapshot) para permitir operações de desfazer/refazer. O padrão Observer é bem representado por System.EventHandler, facilitando a notificação de eventos. O padrão State é usado em Threading.Thread através do ThreadState, e o namespace System.Security.Cryptography permite a escolha de diferentes algoritmos, como MD5, SHA1, e SHA256, aplicando o padrão Strategy.

O método Control.Render no ASP.NET segue o padrão Template Method, definindo uma estrutura para a renderização de controles. Por fim, Xml.XmlDocument implementa o padrão Visitor, permitindo a execução de operações em uma estrutura de documento XML sem modificar as classes dos elementos.

Eu poderia continuar com outros exemplos, pois isso é aplicável a diversos frameworks e bibliotecas, tanto de front-end quanto de back-end, e até mesmo a outros paradigmas, como o funcional. Muitas vezes, utilizamos padrões de design no cotidiano sem estarmos cientes de seus nomes ou de como funcionam detalhadamente.

Conclusão

Meu post é mais otimista em relação ao livro porque, mesmo para criticar ou expressar uma opinião na mesa de desenvolvedores da sua empresa, é essencial lê-lo. Mesmo que você o considere sem valor ou uma total perda de tempo, o fato de ser um clássico extremamente influente já justifica a leitura.

O maior aprendizado para mim é que, mesmo que eu não use os design patterns diretamente, quem construiu o framework que utilizo os usou em várias partes dele. Como é o caso dos exemplos do .NET que dei. O mesmo vale para quem desenvolveu a linguagem que eu uso, mesmo que seja de um paradigma diferente da orientação a objetos. Eu recomendo pesquisar sobre isso se tiver interesse, pois há muitos exemplos, mas não quero me alongar. Se você deseja ir além do superficial como desenvolvedor de software e entender o porquê de cada coisa, por que esse framework funciona de determinada maneira e não de outra, e como escrever software de forma a facilitar sua vida e a de todos, estudar os design patterns é essencial.

Criei um repositório no GitHub com exemplos práticos de todos os "Design Patterns" em C#. Você pode conferir em Design Patterns em C# [PT-BR] - Github

Primeiros Meses como Nômade Digital [PT-BR]

André N. Darcie — Mon, 03 Jun 2024 23:47:12 +0000

Introdução

Estou vivenciando o período mais surpreendente e único de toda a minha vida. Tudo começou após meu aniversário de 30 anos, quando decidi me aventurar como nômade digital. Inicialmente, passei um tempo em Juiz de Fora, Minas Gerais, segui para Vitória, Espírito Santo, e agora estou em Salvador, Bahia. Estou aberto a explorar muitos outros destinos que a vida possa me reservar.

É fantástica essa possibilidade de conhecer uma cidade, seus pontos turísticos, mas além disso, conhecer realmente como é o dia a dia, a rotina, as pessoas, os lugares, a cultura local, a forma de pensar, fazer amigos, as coisas boas e ruins, uma experiência antropológica. Como disse Abujamra, "Um periscópio sobre o oceano do social." O que mais me surpreendeu, no fim, foi que eu me conheci muito mais, pois me expus a novas pessoas sem medo e sem receio, dada a liberdade da minha nova vida, pude ser completamente eu.

Motivação

Percebi que, enquanto nos distraímos, a vida simplesmente acontece ao nosso redor. Constatei que passei quase toda a minha vida nos mesmos lugares, mantendo a mesma rotina. Morei grande parte desse tempo em minha cidade natal e, posteriormente, na cidade onde inicialmente exerci meu trabalho presencial.

Ter a possibilidade de trabalhar remotamente de qualquer lugar com internet é um privilégio imenso. Basta colocar o notebook na mochila, roupas na mala de bordo, e seguir de coração aberto, sem destino. Viajar apenas durante as férias, duas vezes ao ano, não é suficiente para mim. A visão meramente turística, roteirizada e mecânica, não captura a essência de um lugar. Vivenciar o dia a dia é tão diferente; você se acostuma com o local, sente falta das ruas onde morava, dos amigos que fez, e das conversas profundas que teve com pessoas completamente diferentes que fizeram seus olhos brilharem.

Construí meu lar com minhas coisas, meus bens, minhas plantas, flores, quadros, arte, livros e presentes de amigos. Mas, depois de construir tudo, nada é melhor do que destruir e reconstruir tudo de uma maneira completamente diferente.

É como ser um hobbit que decide deixar o Condado. No Condado, temos a família, os amigos, as bebidas, o tabaco no cachimbo e o conforto. Olhar para a estrada sem ter certeza de nada, enfrentar os perigos do mundo – a jornada parece sombria e distante. Mas, assim como Bilbo, nunca me arrependi. Quando ele voltou, tinha histórias para escrever e nunca mais foi o mesmo.

Como funciona?

Acredito que o aspecto mais interessante para quem deseja iniciar ou avaliar a viabilidade desse projeto é poder fazê-lo com um amigo. Meu amigo e eu trabalhamos na mesma empresa e ambos temos a flexibilidade de trabalhar 100% remotamente, o que nos permite dividir o custo do Airbnb, que é o elemento mais caro e crucial. É essencial que o local escolhido esteja completamente mobiliado e pronto para morar, equipado com itens essenciais e, principalmente, uma internet confiável, além de uma mesa e cadeira adequadas para o trabalho. Todo esse ambiente precisa acomodar confortavelmente duas pessoas.

Inicialmente, o Airbnb pode parecer caro, pois muitas pessoas o utilizam para estadias curtas. No entanto, quando você reserva por um período maior, como um mês ou dois, o valor diminui. Dividindo o custo entre duas pessoas, acaba saindo praticamente o mesmo que alugar um lugar sozinho, embora isso possa variar bastante.

Para viajar de uma cidade para outra, usamos ônibus ou, para distâncias maiores, avião. Na cidade, utilizamos o Google Maps, TripAdvisor, TikTok e Instagram para explorar e conhecer pessoas, perguntando sobre lugares interessantes para visitar, pontos turísticos, restaurantes, passeios, parques, museus, festas e baladas. Usamos aplicativos como 99 e Uber para nos locomover.

Carrego comigo uma mochila com o essencial para trabalhar: notebook, mouse, base para o notebook, carregador e fone de ouvido. Além disso, levo uma mala de bordo com todas as minhas roupas e itens pessoais. O restante, como itens consumíveis, compro na cidade onde estou.

Experiências

Juiz de Fora - Minas Gerais

Até mesmo a casa em Juiz de Fora, com o livro da Rita Lee, me deixou totalmente apegado. Aquela casa parecia guardar a história de uma família que viveu grandes momentos. E que delícia foi experimentar a comida local! O show do Sepultura foi emocionante, a roda punk, e beber na lâmpada foi uma experiência única e divertida. Fumar charuto e saborear a comida típica foram prazeres que nunca esquecerei. Visitar o Bar Viking e participar do sorteio da roleta foi uma aventura emocionante.

Explorar o Museu Mariano Procópio foi fascinante; os jardins, o casarão e o museu com suas estátuas em estilo clássico, obras de arte e animais empalhados foram incríveis. O Museu da História do Brasil, com o famoso quadro do Tiradentes, foi uma viagem no tempo. Provar o melhor bacalhau com nata da vida, em um restaurante construido dentro de uma pedra gigante com agua escorrendo, depois pra ir embora se perder nos becos.

Visitar o Museu do Poeta Murilo Mendes e o centro histórico foi enriquecedor. Subir no Morro do Imperador e apreciar a vista de toda a cidade, ver o Cristo diferente, comer um sorvete delicioso, seguir pela trilha e depois voltar.

Vitoria - Espírito Santo

Em Vitória, foi a primeira vez que vi a praia e senti a areia sob meus pés. Comer caranguejo foi uma experiência desafiadora e divertida; passei horas tentando e até fiquei sujo, mas valeu a pena! Sentir o cheiro da maresia todos os dias era revigorante, até a água do banho parecia diferente. Saborear carne de peixe fresca, dançar muito no Vitória Pub, várias vezes com amigos e até na despedida, foi maravilhoso. Ver tartarugas pequenas, médias e até gigantes no Projeto Tamar.

Passava as noites sentado na praia, observando os aviões passarem, o mar, as estrelas no céu aberto, sentindo a brisa suave passar pelo meu corpo. Foram momentos de paz que nunca havia sentido antes. Visitei o Convento da Penha, com uma vista indescritível e um lugar antigo cheio de história. No pico, dava para ver várias praias e toda a cidade, tanto Vitória quanto Vila Velha.

Dancei muito, comi muito e ri muito. Vi a estatua de Yemanjá, vi as ondas e a ponte gigante e curvada. Experimentei pela primeira vez a pizza oficialmente napolitana, andei de patinete elétrico, saboreei moqueca, chopp de sabores variados, café e chocolate amargo, frutos do mar, ostras, e um sofisticado macarrão com vinho. Fui a uma festa de aniversário no parque, caminhei pelas ruas sem destino à noite, conheci pessoas únicas e fui a um restaurante colorido e artístico.

Visitei o Museu de Arte do Espírito Santo, vi os prédios históricos do centro, os monumentos, tomei canelinha e dancei com amigos antes de me despedir. Peguei um avião pela primeira vez na vida. Cada momento foi inesquecível e Vitória se tornou um lugar especial no meu coração.

Ao caminhar pelas praias e sentir a areia entre os dedos, olho para o horizonte e me dou conta de como sou afortunado por estar aqui, por viver este momento.

Salvador - Bahia

Cheguei em Salvador e fui diretamente para o Pelourinho. Lá, vi capoeira, casas coloridas, museus históricos e a Igreja de São Francisco, que foi como parar no tempo. Nunca vi tanto ouro e tanta arte contida em um só lugar. As inscrições em latim "a morte vem para todos" me marcaram profundamente. Sem dúvida, é a igreja mais bonita que já vi na vida, cheia de história. Experimentei carne de sol e conheci a primeira sorveteria do Brasil. Visitei o lugar onde Michael Jackson dançou, vi o Elevador Lacerda e fui ao Bar do Preto.

A cada dia que passa, sinto meu coração bater mais forte por Salvador. Estou encantado, apaixonado, transformado. Este lugar, com suas histórias e sua gente, está me mostrando um novo jeito de viver, mais leve, mais alegre, mais pleno.

Provei o famoso Acarajé da Cira, fui à Praia da Barra, visitei o Museu Náutico e assisti ao pôr do sol. Fui ao farol pela primeira vez, vi canoas e navios, andei de caiaque, comi açaí com chocolate, observei a praia lotada e a alegria do povo, ao lado de um carnaval vibrante. Visitei a casa de Jorge Amado e vi seus amigos poetas, artistas, músicos e diretores de cinema. Ali, percebi que uma parte significativa da cultura brasileira foi criada. Assisti ao meu primeiro jogo de futebol oficial, vi a torcida gritar, chorar, comemorar e reclamar, cantar em sincronia. Comi carne de sol com farofa, sentei ao lado de uma estátua e saboreei o melhor vatapá da minha vida.

Cada esquina uma nova aventura. O cheiro do acarajé fritando na rua, as cores vibrantes das vestes baianas, o som dos tambores que ecoam nas ladeiras do Pelourinho – tudo isso me faz sentir mais conectado com as raízes do nosso país. A energia de Salvador é contagiante e vou continuar por aqui por um bom tempo.

Conclusão

Está valendo a pena? Já bateu o arrependimento? Sinto saudades da minha família e amigos, mas tenho um medo profundo de, em outra dimensão, eu ter decidido ficar. Já sou uma pessoa diferente; vi e conheci coisas que nunca imaginaria que existiam. Amei sair para caminhar depois do trabalho na praia em Vitória, amei os amigos que fiz lá, os museus e as histórias, as noites. Agora, estou completamente apaixonado por Salvador. Que brasileiro sou eu que não conhecia Salvador, a primeira capital do Brasil! O Brasil é extremamente rico em cultura e diversidade; estou de coração aberto, nunca senti essa paixão arder dentro de mim de maneira tão intensa, de estar vivo e poder aproveitar tudo o que a vida oferece.

Agradeço imensamente por ser um nômade. Ser capaz de explorar diferentes cantos do Brasil, cada lugar com suas particularidades e belezas únicas, é um privilégio inestimável. Compartilho todas essas experiências e aprendizados no meu Instagram @andre.darcie. Sinto-me profundamente grato e animado para continuar essa jornada, descobrindo e vivendo intensamente cada momento.

Muito obrigado pelo seu tempo e atenção em ler até aqui. Espero que este texto tenha te motivado e encantado de alguma forma. Sinta-se à vontade para perguntar qualquer coisa! 😊

DEV Community: André N. Darcie

Agentes de IA exigem TDD: o passo a passo necessário para aplicar na prática [PT-BR]

O que é TDD?

Ameaça e defesa

Passo 1: Definir os requisitos

Passo 2: Visualizar o fluxo

Passo 3: Criar a classe sem implementação (RED)

Passo 4: Escrever os testes (RED)

Passo 5: Fechar o agente e abrir uma nova sessão

Passo 6: Implementar para passar nos testes (GREEN)

Passo 7: Identificar os problemas (REFACTOR)

Passo 8: Refatorar (REFACTOR)

Passo 9: Confirmar que tudo ainda passa

Passo 10: Testar manualmente e em homologação

Conclusão

TDD Is No Longer Optional in the World of AI Agents

Inverting the process

Why this works

Bugs too

A good practice that became mandatory

Qwen3.5 rodando localmente: super rápido e com ótima qualidade

LLM local

Performance

Instalação

Impressão geral

A IA fez o trabalho de vários membros da minha equipe, e isso vai gerar demissões

Gone Home: o jogo que destruiu as regras e construiu um novo sentido para videogames [PT-BR]

Introdução

Jogo

Influência

História

O valor das experências

Comparação com a indústria

Conclusão

Entenda DDD de uma vez por todas, na implementação [PT-BR]

Introdução

O que o DDD é

O que o DDD não é

1. Conceitos Fundamentais do DDD

1.1 Linguagem Onipresente (Ubiquitous Language)

1.2 DDD Não é Sobre Arquitetura, é Sobre o Domínio

1.3 Mapa de Contexto (Context Map)

1.4 Simplicidade e Clareza

2. Implementação

2.0 Entidade Pagamento

2.1 Entidade PedidoDePagamento

2.2 Value Object MetodoPagamento

2.3 Fábrica PedidoDePagamentoFactory

2.4 Repositório IPedidoDePagamentoRepository

2.5 Serviço de Domínio ProcessadorDePedido

2.6 DbContext PagamentosDbContext

2.7 Repositório Concreto PedidoDePagamentoRepository

3. Estutura final da implementação

3. O Que Não Foi Utilizado do DDD Nesta Implementação

4. Conclusão

Como modelar microserviços corretamente? [PT-BR]

Introdução

Como modelar microservices corretamente?

Como fazer uma boa fronteira?

Tipos de acoplamento

DDD e Microservices

Por que DDD casa tão bem com microservices?

Alternativas ao DDD

Referências e Leituras Recomendadas

Quando NÃO usar microserviços [PT-BR]

🆕 Seu produto é novo

👥 Sua empresa/equipe é pequena

📈 Você não precisa de grande escala

🛠️ Seu código está acoplado e desorganizado

Conclusão

Me obriguei a assistir a 250 filmes clássicos do cinema, e aqui está o que aprendi. [PT-BR]

Introdução

Viagem

Senso Critico

Valor de um clássico

Filmes que ensinam filosofia

Conheci grandes diretores e suas obras primas

Contemplação

O valor dos criticos

Conclusão

2.0 Entidade `Pagamento`

2.1 Entidade `PedidoDePagamento`

2.2 Value Object `MetodoPagamento`

2.3 Fábrica `PedidoDePagamentoFactory`

2.4 Repositório `IPedidoDePagamentoRepository`

2.5 Serviço de Domínio `ProcessadorDePedido`

2.6 DbContext `PagamentosDbContext`

2.7 Repositório Concreto `PedidoDePagamentoRepository`