DEV Community: André N. Darcie

Making of Tiny RPG Studio

André N. Darcie — Sun, 28 Jun 2026 17:42:59 +0000

This is the story of how I created Tiny RPG Studio: a small engine for simple RPGs, built to help people make their first games without needing to program.

At its core, it came from an idea that took me years to understand clearly: sometimes the best tool is not the one that lets you do everything, but the one that gives you just enough limits to finally finish something.

Childhood, RPG Maker, and the Static World

When I was a child, my aunt gave me a PC with Windows XP. I still did not have internet access, but I explored that computer as if it were the most interesting and exciting thing I could possibly have.

I used to ask people to download games for me. Once, I bought a rewritable CD and went to a friend's house because he had internet. He opened Baixaki, and we started looking for programs he could download so I could burn them to the CD and install them on my computer later.

I remember once telling my cousin: "the internet is magic, I can download anything, learn about anything, and one day, when I have it, no one will stop me."

While browsing Baixaki, a Brazilian download site, I saw a category that caught my attention: "game creators." At the time, I was already addicted to PlayStation 1, playing Resident Evil and Silent Hill, so the idea that I could create my own games felt insane.

I downloaded things like Engine 001 and RPG Maker.

RPG Maker was incredible because it already came with ready-made sprites, an RTP package with characters, maps, objects, and amazing pixel art. I did not know pixel art, so that whole visual side was already partly solved for me.

I quickly learned how to build visually interesting maps with sprites, place NPCs in the world, and write dialogue for them. At that point, I really had my first game, and that felt like an unprecedented idea.

I remember telling a cousin: "I found a different kind of game, where you create games inside it." In other words, I did not really understand the concept of a game engine yet.

Eventually, I reached a point where I had created that world, but everything was static: the scenery, the NPCs, the monsters, even the story. Everything existed, but nothing could change.

I wanted to do something simple and even a bit cliche: a king in his castle would ask me to kill a dragon that was terrorizing the village. So I would go there, defeat the dragon, and come back to talk to the king.

But the king did not know I had done it.

And I asked myself: how could I solve this?

Searching through forums and tutorials on Google, I found something called "Switches." They could have two states: ON and OFF.

So when I defeated the dragon, I would turn the Switch ON. When I returned to the king, he had his default dialogue, but he also had an alternate dialogue if the Switch was ON. Something like: "You killed the dragon and saved the village."

I did not know exactly what I was doing, but it worked. So I started creating switches for all kinds of things, even to check whether it was day or night in the game world.

Discovering Programming

Much later, I started a technical IT program, a two-year course I took alongside high school. I wanted to learn programming.

That had a big impact on me because, at that point, the computer meant everything to me, but I was still just a passive user, using things created by other people. The idea that I could become a programmer and create things from my own ideas, for other people to use, felt surreal.

In the first programming logic classes, the teacher explained what a conditional is, what an IF is: if yes, do this; otherwise, do that.

Before that, instructions felt like a fixed sequence, like a recipe. But then something new appeared: a branch in the flow. A condition.

And I had a huge epiphany.

That Switch from RPG Maker was exactly the conditional I had been using to change the king's dialogue. So, in a weird way, I already knew programming long before I knew that I knew programming.

I even remember writing some code and asking the teacher what he thought. He said: "Everyone, this is interesting. He did it differently from how I taught it, but it will also work. This shows that there are many ways to write code."

Aside from art class in elementary school, that was the second time in my life I started getting praised in class. It happened in programming class, not because I was great at math or logic, but because I had already learned all of that from RPG Maker.

Bitsy and the Value of Limitations

Then came a big time jump. I had already graduated in computer science, was working my first job as a programmer, and was creating small game projects with plain code, now in JavaScript. I also knew how to make games in Unity with C#.

Through those projects, I discovered itch.io, which is huge, and found tools like Twine, for creating text games with choices; PICO-8, a fantasy console for making retro minigames; and Bitsy, a tiny engine for creating narrative games with three colors and simple pixel art.

Bitsy gave me another epiphany.

I used to think that creating a game engine like Unity or Unreal was an absurd idea. My role was to be a high-level application developer. I do not consider myself a programming genius like Linus Torvalds with the Linux kernel, so learning low-level GPU programming just to consider creating an engine felt way too distant.

But I had never stopped to think about creating a high-level engine in JavaScript, using Canvas, where all the low-level details could be ignored. The focus could be something else: creating an accessible tool, easy to use, and capable of running even on a phone.

An engine that is simpler to build and also simpler for people to make games with. No need to know programming. No need to take courses or watch tutorials just to build something basic.

I immediately thought: "I wish I were the person who created Bitsy, because that idea is absurdly brilliant."

Instead of competing with RPG Maker, Godot, or Unity by trying to offer more features, more performance, and more tutorials, Bitsy goes in the opposite direction. It serves the needs those tools do not serve as well: accessibility, simplicity, and a very low barrier to entry.

One of the best games I ever created was Zero to One, made in Bitsy for a game jam called One Room.

It was the best game I had created precisely because I never managed to finish my more ambitious games, the ones with long scripts, lore, worlds, systems, and brilliant ideas.

I am very bad at creating something with a limited scope. I define a scope and immediately want to expand it with incredible ideas that appear all the time. I take a shower and come back with five more ideas for the game. That makes the game impossible to finish. After a few months, I give up and already want to make another game that feels even more brilliant.

But Bitsy does not let that happen so easily. It is limited by default. You are forced to reduce the scope and tell a direct story there.

So I wrote a simple script, created three scenes, finished the game, and released it within the limited time of the game jam.

In other words, all my problems were solved there: I finally had a solid little game released online.

Bitsy stands alongside major engines in terms of the number of games created precisely because it is easy and fast to make something and release it. Without a doubt, it helped people who had never thought about creating games actually create games.

Taking a Break from Game Dev

After years of making games, after creating paid games and taking Godot courses, after deciding that my biggest life goal was to release a game on Steam, I gave up on game dev.

Imagine spending every night for a year creating a game, putting effort and work into it, and in the end, after a year and a half, having only the beginning of a game. The art was not ready, the gameplay was not smooth enough, and the puzzles were not good.

Once again, I had been too ambitious and could not finish my game.

After that, I thought: how many games are released on Steam? On itch.io, how many brilliant games appear every day? Does the world need more games? Or does it specifically need my games?

The work, bureaucracy, and frustration you need to go through just to make a simple game are heavy. That is why I completely gave up on it for a while.

Returning with AI

The arrival of AI had a major impact on programming. I started using ChatGPT to help me create C# classes, write SQL queries for work, and solve project errors.

You know that annoying error you have no idea how to solve? Before, I would go to Google, read several forums and posts, then go to Stack Overflow, find nothing, think about asking a question, and already imagine getting torn apart in the replies.

That summed up my experience as a programmer pretty well: moments of joy and moments of frustration.

Then I started copying the entire error message and sending it to ChatGPT. It gave specific and useful solutions. I would go back, apply them, and solve the issue. It was rudimentary, but it worked.

Over time, I began to realize that many errors could be solved in record time. When a coworker asked me for help, I would send their error to ChatGPT and solve it in minutes. Sometimes they had spent the entire day stuck on it.

They would say: "wow, you solved my error that fast? I lost the whole day on this, you really are a programming genius." I would laugh and say: "I sent it to the chat."

After a while, everyone started doing the same thing and no one asked me for help anymore.

I became excited about the potential of AI to remove the frustrating part I never liked and let me focus on the part where I could be better: being creative, having ideas, and giving direction.

When GPT-5 came out, I started creating small web games with HTML, JS, and CSS directly through chat. This was in 2025. I found it fascinating and applied the same philosophy of small projects: creating minigames and short stories.

I had the idea of creating a mini-RPG using Canvas, based on my previous projects. It quickly created something playable, and then I thought: now we need a small editor for this, so I can actually create this game properly.

And it did.

It was a small MVP, made with a one-shot prompt, but it turned out well and, surprisingly, it worked.

I left the project aside for a while, until I realized that, for it to become something real, I needed to take it out of the chat, put it in an editor like VS Code, and start working on it properly.

At the time, everyone was talking about Cursor, a fork of VS Code focused on working with AI. I downloaded it, got the free version with some credits, and put the project there. It started evolving brutally fast.

I showed the project to Diego and he doubted it: "I want to see if this is really working." It looked magical and had been made too quickly.

But when I tried to add something new, the project broke badly. I kept asking the AI to fix it, tried several prompts, and nothing worked. Since the code had been generated by AI, I also did not understand everything, and fixing it alone would take a lot of time.

At the time, I thought: "I hit the limit of AI here."

Then tools like Claude Code and Codex arrived, with agents better prepared to work on code projects. When I saw that Codex was available for ChatGPT subscribers, I came back to the project.

Codex solved the fatal bug, improved a few things, and got the tool ready to launch in just a few days.

We have to consider that I had already given up on game dev. My routine had become that of an adult with no time for unpaid personal projects. Spending nights fixing bugs and debugging was no longer realistic.

So I saw that the most tedious manual work could be handled by AI, while I focused on being creative, having good ideas, expressing myself as an artist, and applying software engineering. That is the reason I came back to game dev and to the community, and why I felt it was worth creating a small game engine.

This project would not exist without the beginning with GPT-5 and the maintenance with Codex.

Launch, Community, and Engineering

Since the engine was an MVP, a prototype, there was still a lot to polish, improve, and fix.

Diego, who has always played my games and projects, started collaborating a lot. He helped the tool become good enough to launch, not only by testing and finding bugs, but also by helping solve code problems, giving constant feedback, and promoting it through game jams.

I think that made the difference between the engine being seen by someone and being completely forgotten among millions of projects out there.

In the end, promotion is one of the most important parts of a project. As the saying goes, "marketing is the soul of the business." If you create an incredible tool and no one knows it exists, what is the point?

By the end of 2025, the engine had already launched. People were creating games with it, game jams were happening, the community was growing, and I even posted about it on LinkedIn.

Then came the part I value most in the project: applying my knowledge of programming, software engineering, and best practices to turn it into something beyond a prototype.

Until that point, I had mostly been deciding the creative direction and how the features would work. I had not yet thought that much about code and architecture, because it was a simple project made for people who do not have much time.

But with the success of the tool, I decided to apply everything I knew about code. It was fascinating, because I learned things that I took to work, presented in a talk, and used to help other developers: how to build something high-quality with the help of AI agents.

I decided to try Claude Code, paying for it instead of using a free version, because there is no such thing as a free lunch. I made the biggest migration in the history of the project, moving the entire codebase to TypeScript, with aggressive linting, unit tests, functional tests, and a code quality pipeline.

I created an architecture, organized folders and structure, applied SOLID, and started using best practices I had learned from college and from every company I had worked at.

That was when the project became much more robust. If I change something that breaks something else and creates a bug, I find out immediately, because there are tests covering many scenarios.

In that second phase, the engine became a serious project, something people could use and trust. With the game jams hosted by Diego, promotion gained strength, and today we have a very active community using the engine every day.

The Philosophy of Tiny RPG Studio

The philosophy of Tiny RPG Studio is the same one from the beginning of this post: creating an accessible tool for people who are just starting out.

I created a game in RPG Maker, used boolean variables, used Switches, and it was so easy that I did not even know it could already be considered programming.

The sprites already existed. I did not need to know pixel art or programming. Even so, I was able to create stories and adventures.

Now I have reached a point in life where I can create my own engine for other people to use. Maybe it will be their RPG Maker. Maybe it will be the first engine of their lives. Maybe it will be where they create the first game they actually finish.

I would never try to create an RPG Maker competitor, the same thing but better. That would be impossible. But I could take the minimalist philosophy of Bitsy and create something in that direction.

In the end, creativity is also about building on solid and brilliant things other people made before you, standing on the shoulders of giants, and then adding your own special touch.

I feel that Tiny RPG Studio is something new because it is absurdly simple to use.

You do not need even the bare minimum of pixel art, programming, or knowledge of how to create a scene with a teleport event from one place to another.

The game world is fixed, limited, and already interconnected, like a tiny open world. Even that comes built in.

The interface is simple and intuitive even on a phone, because the project was born mobile-first. And because I still think generating an HTML build, downloading it, and hosting it is too much work, the engine focuses more on generating a URL.

You create your game, generate a URL, and send it to your friends. The URL already contains the entire game. There is nothing else to download.

I cannot imagine a simpler way to create a mini-RPG, and I feel very proud of this project.

In the end, Tiny RPG Studio was born from this cycle: discovering games, discovering programming, giving up on projects that were too big, and coming back with a tool small enough to actually exist.

If it helps someone create the first game of their life, then it was already worth it.

O mínimo que você precisa saber para desenvolver software com IA

André N. Darcie — Sat, 27 Jun 2026 12:18:58 +0000

⏱️ Tempo de leitura: aproximadamente 3 minutos.

Seja um engenheiro de software. A IA é uma ferramenta, não substitui conhecimento de arquitetura, engenharia e boas práticas.
Não terceirize decisões para a IA. Requisitos funcionais e não funcionais devem ser definidos por você. Seja específico e pense até nos menores detalhes.
Não existe almoço grátis. Modelos gratuitos, versões mais baratas ou rodar modelos locais ainda ficam atrás dos melhores modelos para desenvolvimento profissional.
Hoje, os modelos mais viáveis para engenharia de software são o Opus e o GPT usando o maior nível de raciocínio ("high effort"). Utilizar modelos inferiores geralmente aumenta o retrabalho, fazendo você gastar mais tempo e consumindo o tempo de outras pessoas revisando e corrigindo erros.
Use agentes de IA rodando no seu computador. O harness faz uma diferença enorme na qualidade. Para GPT, use o Codex. Para Opus, use o Claude Code. Ferramentas com harness inferior normalmente entregam resultados inferiores, mesmo usando o mesmo modelo. Afinal, por que uma empresa terceirizada conseguiria criar uma ferramenta que extrai mais de um modelo do que a própria empresa que o desenvolveu?
Planos mais baratos de IA servem para projetos simples ou amadores. Em projetos profissionais, considere investir em planos que ofereçam acesso aos melhores modelos e maior capacidade de uso.
Todo projeto deve possuir um CLAUDE.md ou AGENTS.md. Mantenha esse arquivo curto, objetivo, em inglês e contendo apenas as informações realmente importantes do projeto.
Nunca implemente diretamente. Analise o problema, crie um plano, revise esse plano e só então implemente. O plano deve conter arquitetura, critérios de aceitação, testes, validações e feedback loops.
Seja cético com o plano. Revise tudo antes de implementar. Peça para a IA identificar lacunas, fazer perguntas e desafiar suas decisões. A IA só deveria errar por não seguir um plano bem definido.
Desenvolva senso crítico. A IA acelera a execução, mas não substitui julgamento, criatividade e decisões de engenharia.
Mude seu papel. Deixe de ser apenas quem implementa tarefas. Passe a atuar como arquiteto, tech lead e product owner, pensando no sistema como um todo.
Contexto é tudo. Um único prompt não basta. Forneça regras de negócio, arquitetura, convenções, exemplos e restrições, mas apenas o que for realmente relevante para a tarefa. Contexto insuficiente reduz a qualidade das respostas, enquanto contexto desnecessário aumenta custo, dificulta o foco do modelo e pode piorar os resultados.
Prefira evoluir em pequenas etapas. Em vez de pedir uma funcionalidade inteira de uma vez, divida o trabalho em incrementos pequenos, valide cada etapa e só então avance para a próxima. Isso reduz retrabalho, facilita revisões e aumenta a qualidade do resultado final.
Sempre valide automaticamente. Todo ciclo deve terminar executando build, testes, linters, formatadores e análise estática.
Não aceite código apenas porque funciona. Exija legibilidade, simplicidade, segurança, observabilidade, testes e manutenibilidade.
Use skills para padronizar prompts. Elas evitam que você precise reescrever instruções repetitivas para tarefas feitas constantemente, mantendo o mesmo padrão de qualidade, arquitetura e validação em todos os projetos.
Se analisar, planejar, revisar e testar parece trabalho demais para você, talvez não valha a pena usar IA para desenvolver software. Sem esse processo, a tendência é gerar código de baixa qualidade, aumentar o retrabalho e criar problemas que custarão muito mais tempo para corrigir depois.
A responsabilidade é sempre sua. No final, você é responsável por cada linha de código que chega à produção. Não culpe a IA, as ferramentas ou terceiros. No fim, quem a empresa vai cobrar é você.

A IA não vai pensar por você. E isso é uma coisa boa.

André N. Darcie — Fri, 26 Jun 2026 16:21:58 +0000

Eu vejo muita gente esperando que a IA aja como um engenheiro de software sênior. Que ela tome decisões de arquitetura, escolha as melhores práticas, pense em escalabilidade, segurança, performance... tudo sozinha.

Sinceramente, eu acho que essa expectativa está errada.

No funcionamento mais básico, um LLM pega o seu prompt e prevê os próximos tokens mais prováveis. Depois existe o pós-treinamento, com validação humana, mas no fim ela continua sendo guiada pelo que você escreveu.

E aí vem o ponto.

Se você não disse que queria SOLID, por que ela deveria aplicar SOLID?

Se você não pediu Repository Pattern, por que ela deveria criar um?

Se você pediu uma API simples, por que ela deveria gastar mais tokens criando uma arquitetura cheia de camadas?

Ela estaria assumindo coisas que você nunca pediu.

E assumir coisas nem sempre é bom.

Todo mundo pensa apenas no lado positivo:

"Seria legal se a IA tomasse boas decisões sozinha."

Mas existe o outro lado.

Ela pode decidir usar uma biblioteca que você não queria, criar dependências desnecessárias, aumentar a complexidade do projeto ou até gerar um vendor lock-in que você nunca escolheu.

É por isso que eu acho que a IA não deveria decidir essas coisas por conta própria.

Ela deveria executar exatamente o que você pediu.

Por exemplo, quando eu quero adicionar logs em um projeto, eu não escrevo simplesmente:

"Adicione logs."

Eu escrevo algo mais próximo de:

Utilize Serilog, siga a documentação oficial, implemente seguindo as boas práticas da biblioteca e mantenha o padrão do projeto.

Agora sim ela tem contexto.

Ela sabe qual biblioteca usar, qual documentação seguir e qual padrão eu espero.

O mesmo acontece com qualidade de código.

Se eu fico uma semana inteira pedindo só feature, feature, feature, feature... o débito técnico vai aparecer.

Mas a culpa não é da IA.

Eu nunca pedi para ela reorganizar o projeto.

Eu nunca pedi um code review.

Eu nunca pedi para separar responsabilidades.

Então, de tempos em tempos, eu paro e faço prompts específicos para qualidade.

No Tiny Theft Auto (meu pequeno projeto inspirado em GTA) foi exatamente assim.

O projeto começou como um único index.html.

Quando eu decidi que ele iria crescer, fui eu quem falou:

aplique o SRP;
separe uma classe por arquivo;
reorganize toda a estrutura;
faça um code review;
levante pontos de melhoria para eu decidir se vale a pena corrigir.

Essas decisões foram minhas.

A IA só executou.

Isso acontece também em empresas.

No meu trabalho, por exemplo, existem padrões internos para logs, observabilidade, testes e várias outras coisas.

Eu não espero que a IA adivinhe qual padrão usar.

Eu passo a documentação, a skill ou o template da empresa e peço para ela seguir aquilo.

Ela deixa de "inventar" arquitetura e passa a implementar o padrão que já existe.

No fim, eu acho que a maior mudança de mentalidade é essa:

Nunca terceirize pensamento. Terceirize o braço.

Quem decide arquitetura é você.

Quem decide escalabilidade é você.

Quem decide boas práticas é você.

Quem decide qual biblioteca usar é você.

A IA serve para executar essas decisões com muito mais velocidade.

Porque, no fim das contas, ela não é um engenheiro de software tomando decisões por você.

Ela é um multiplicador da produtividade de quem sabe exatamente o que quer construir.

Claude Fable 5 me permitiu criar GTA em apenas um prompt.

André N. Darcie — Tue, 09 Jun 2026 21:02:35 +0000

Claude Fable 5 me permitiu criar um "GTA" em apenas um prompt.

Prompt:
"Crie um jogo, Tiny GTA 3D."
A própria Anthropic afirma que o Fable 5 é seu modelo mais poderoso já lançado ao público, com avanços significativos em engenharia de software, pesquisa científica, visão computacional e execução autônoma de tarefas complexas. Em testes iniciais, empresas relataram que o modelo foi capaz de comprimir meses de trabalho de engenharia em poucos dias.

Cidade 3D aberta com 64 quarteirões, prédios, parques e oceano
Dirija, roube carros e fuja da polícia
Sistema de procurado com 5 estrelas, viaturas e helicóptero te perseguem
42 pedestres vivos que fogem, voam e morrem
16 missões de entrega com histórias de corrupção brasileira
Áudio sintetizado: motor, sirene, buzina e cantada de pneu
Recorde salvo no navegador

Jogue aqui: https://andredarcie.github.io/tiny-gta/

Ideias Valem Muito Menos do Que Você Imagina [PT-BR]

André N. Darcie — Sat, 30 May 2026 21:19:18 +0000

A notícia da venda do Downdetector e do Speedtest para a Accenture por US$ 1,2 bilhão trouxe um comentário que aparece sempre que uma empresa de software faz sucesso:

"Mas eu consigo programar isso em um fim de semana."

Talvez consiga mesmo.

Mas isso não significa que você conseguiria construir o negócio.

O software é apenas uma pequena parte.

Criar um site que mede velocidade de internet não é particularmente difícil para um desenvolvedor experiente.

Existem diversos clones e projetos open source que fazem algo parecido.

O próprio fundador de um concorrente da Ookla comentou que criou sua primeira versão durante um fim de semana em 2008.

O detalhe importante é que ele levou 18 anos para transformar aquilo em um negócio relevante.

O que realmente tem valor?

Mas o valor normalmente está em outros lugares:

Distribuição
Marca
Confiança dos usuários
Relacionamento com empresas
Estratégia comercial
Dados acumulados ao longo dos anos

O verdadeiro produto eram os dados

Segundo pessoas do setor, o principal negócio não era o teste de velocidade em si.

Milhões de usuários realizam testes diariamente e geram informações valiosas sobre redes de internet ao redor do mundo.

Esses dados ajudam operadoras a identificar gargalos, comparar desempenho e planejar investimentos.

É por isso que empresas pagam valores altos para ter acesso a essas informações.

Conclusão

A ideia do Speedtest cabe em uma frase.

Se um desenvolvedor construiu um concorrente em um fim de semana em 2008, imagine agora com agentes de IA. Ainda assim, continuarão faltando os 18 anos necessários para transformar aquilo em um negócio vendável.

Afinal, transformar isso em uma empresa bilionária exigiu décadas de execução, operação, marketing, vendas, infraestrutura e construção de confiança.

Ideias são abundantes, podem ser criadas e roubadas o tempo todo.

Execução é rara.

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?

DEV Community: André N. Darcie

Making of Tiny RPG Studio

Childhood, RPG Maker, and the Static World

Discovering Programming

Bitsy and the Value of Limitations

Taking a Break from Game Dev

Returning with AI

Launch, Community, and Engineering

The Philosophy of Tiny RPG Studio

O mínimo que você precisa saber para desenvolver software com IA

A IA não vai pensar por você. E isso é uma coisa boa.

Claude Fable 5 me permitiu criar GTA em apenas um prompt.

Ideias Valem Muito Menos do Que Você Imagina [PT-BR]

O software é apenas uma pequena parte.

O que realmente tem valor?

O verdadeiro produto eram os dados

Conclusão

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

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`