DEV Community: Vitor Fábio

Repensando o fluxo de desenvolvimento de software com o aumento da codificação assistida por IA

Vitor Fábio — Thu, 24 Sep 2026 22:07:58 +0000

A adoção de ferramentas de inteligência artificial no desenvolvimento de software está reduzindo consideravelmente o tempo necessário para implementar muitas tarefas. Atividades que anteriormente exigiam várias horas de investigação, escrita de código e criação de testes podem ser realizadas em períodos menores quando o desenvolvedor utiliza agentes capazes de analisar a base de código, propor implementações e executar parte do trabalho necessário.

Esse ganho é relevante, mas também começa a produzir algumas mudanças no fluxo de desenvolvimento que merecem atenção. Se um desenvolvedor consegue concluir mais tarefas no mesmo período, a consequência natural é um aumento na quantidade de alterações que precisam passar pelas etapas seguintes do processo, especialmente testes, revisão de código e integração.

A capacidade de produzir código, portanto, pode crescer mais rapidamente do que a capacidade do time de revisar esse código.

Na prática, isso pode resultar em um aumento do WIP (Work in Progress), com mais pull requests aguardando revisão e desenvolvedores precisando alternar com maior frequência entre implementação e análise de mudanças produzidas por outras pessoas.

O problema não está necessariamente no uso da IA ou no aumento da produtividade individual. O que talvez precise ser revisto é o processo ao redor dessas ferramentas. Se conseguimos aumentar significativamente a velocidade de uma etapa do desenvolvimento, precisamos entender como as demais etapas podem acompanhar essa mudança sem reduzir a qualidade das entregas ou simplesmente transferir o gargalo para outro ponto do fluxo.

Small batches como forma de reduzir o custo da revisão

Uma prática que pode ajudar nesse cenário é o desenvolvimento em small batches, discutido pelo DORA como uma das capacidades associadas à entrega contínua de software.

A ideia consiste em organizar o trabalho em mudanças menores, independentes e passíveis de validação individual. Em vez de concentrar toda a implementação de uma tarefa em uma alteração extensa, procura-se identificar incrementos menores que possam ser implementados, testados e revisados separadamente.

Em um primeiro momento, essa abordagem pode parecer contraditória para um time que já está lidando com um volume elevado de pull requests. Dividir uma implementação pode efetivamente aumentar o número absoluto de PRs e, se observarmos apenas essa métrica, o processo poderia parecer ainda mais sobrecarregado.

Entretanto, quantidade de pull requests e esforço necessário para revisá-los não são necessariamente proporcionais.

Um PR pequeno, com objetivo bem definido e poucas responsabilidades, tende a exigir menos contexto do reviewer. Também é mais simples compreender o impacto da alteração, identificar possíveis regressões e avaliar se a implementação corresponde ao que foi solicitado.

Essa característica se torna especialmente importante quando parte significativa do código é produzida com auxílio de IA. Um agente pode modificar muitos arquivos e implementar diferentes aspectos de uma funcionalidade em poucos minutos, mas a velocidade com que essas alterações são produzidas não reduz automaticamente o esforço necessário para que outra pessoa compreenda as decisões tomadas.

Por isso, talvez seja útil considerar o tamanho da unidade de revisão como uma restrição independente da capacidade de geração de código.

Ao dividir uma implementação em mudanças menores, também passamos a receber feedback mais cedo. Uma decisão arquitetural questionada no primeiro batch pode ser corrigida antes que ela seja reproduzida nos próximos. Da mesma forma, um problema identificado em uma primeira implementação pode modificar as instruções fornecidas ao agente nas etapas seguintes.

Nesse contexto, small batches não seriam apenas uma forma de facilitar o code review, mas também uma maneira de criar ciclos mais frequentes de aprendizado durante a implementação.

Utilizar automação antes de consumir atenção humana

Outro aspecto que merece ser discutido é o momento em que uma alteração passa a consumir tempo de outro desenvolvedor.

No fluxo tradicional, é comum que o autor conclua uma implementação, abra um pull request e solicite imediatamente uma revisão humana. Durante essa revisão, entretanto, podem surgir problemas relativamente mecânicos, como testes ausentes, inconsistências com padrões conhecidos do projeto, problemas simples de segurança, código duplicado ou situações que poderiam ter sido identificadas por ferramentas automatizadas.

Com ferramentas modernas de análise e code review assistido por IA, parte dessas verificações pode acontecer antes que o pull request seja considerado pronto para revisão humana.

A documentação do GitHub sobre o uso do Copilot Code Review ao longo do ciclo de vida de um pull request apresenta um fluxo semelhante. O PR pode permanecer inicialmente como draft, receber revisões automatizadas e passar por ciclos de correção antes de ser disponibilizado para os demais desenvolvedores.

Isso permite pensar em um fluxo no qual a implementação passa progressivamente por diferentes níveis de validação:

implementação → testes → análise estática → verificações de segurança → revisão por IA → correções → revisão humana.

Essa organização não pressupõe que a revisão automatizada substitua o code review realizado por desenvolvedores. O objetivo seria reduzir a quantidade de problemas que chegam até essa etapa, permitindo que o reviewer dedique mais atenção às questões que dependem de conhecimento do produto, experiência arquitetural e compreensão do contexto da mudança.

Em vez de utilizar parte significativa do tempo apontando problemas que poderiam ser detectados automaticamente, a revisão humana poderia se concentrar em aspectos como adequação da solução ao problema, impacto sobre outras áreas do sistema, complexidade introduzida, decisões arquiteturais e facilidade de manutenção futura.

Transformar padrões de desenvolvimento em critérios explícitos

Para que esse processo funcione de maneira consistente, existe uma questão adicional: as ferramentas automatizadas precisam conhecer os padrões que esperamos das implementações.

Muitas equipes possuem um conjunto considerável de regras que nunca foram formalizadas completamente. Desenvolvedores mais experientes conhecem determinadas convenções porque trabalham no projeto há bastante tempo, participaram de decisões anteriores ou aprenderam esses padrões durante revisões de código.

Quando passamos a delegar uma parcela maior da implementação para agentes de IA, depender exclusivamente desse conhecimento implícito se torna mais problemático.

Uma alternativa seria documentar critérios de engenharia de maneira estruturada e, sempre que possível, utilizá-los também como entrada para ferramentas de desenvolvimento e revisão.

Alguns desses critérios poderiam ser gerais e aplicáveis a praticamente qualquer alteração, como segurança, cobertura adequada de testes, tratamento de erros, compatibilidade com comportamentos existentes, observabilidade quando necessária e aderência aos padrões arquiteturais do projeto.

Outros critérios poderiam ser ativados dependendo do tipo de alteração realizada.

Alterações envolvendo APIs

Uma implementação que cria ou modifica uma API poderia ser analisada considerando, entre outros aspectos:

autenticação e autorização;
validação e sanitização dos dados recebidos;
padronização das estruturas de resposta;
utilização adequada dos códigos HTTP;
escolha dos métodos HTTP;
tratamento consistente de erros;
idempotência quando aplicável;
rate limiting quando necessário;
compatibilidade com consumidores existentes;
testes dos cenários de sucesso, erro e autorização.

Alterações envolvendo interfaces

Para mudanças relacionadas à interface, os critérios poderiam considerar:

consistência com os componentes e padrões visuais existentes;
responsividade;
acessibilidade;
comportamento durante carregamento;
estados vazios e situações de erro;
compatibilidade entre temas, quando aplicável;
experiência de uso;
SEO para páginas em que isso seja relevante;
compatibilidade com os navegadores suportados;
cobertura dos principais fluxos por testes.

Alterações envolvendo persistência de dados

Mudanças relacionadas ao banco de dados poderiam possuir outro conjunto de critérios:

impacto sobre dados existentes;
estratégia de migration e rollback;
índices necessários;
integridade dos dados;
privacidade e exposição de informações;
impacto de performance;
compatibilidade durante o processo de deploy;
comportamento durante atualizações graduais da aplicação.

A mesma lógica poderia ser aplicada a integrações externas, autenticação, processamento assíncrono, infraestrutura, billing e outras áreas relevantes para cada projeto.

Naturalmente, nem todos esses critérios deveriam se transformar em regras rígidas. Alguns podem ser verificados objetivamente por testes ou ferramentas de análise, enquanto outros funcionam melhor como perguntas que orientam a revisão.

O ponto importante é reduzir a dependência de conhecimento exclusivamente tácito e criar uma referência comum para desenvolvedores, agentes de implementação e ferramentas de revisão.

Um possível fluxo de desenvolvimento assistido por IA

Combinando essas práticas, poderíamos experimentar um processo no qual uma tarefa passa pelas seguintes etapas:

entendimento do problema e definição do escopo;
identificação de batches pequenos e independentes;
implementação de um batch;
execução dos testes automatizados;
execução de linters, análise estática e verificações de segurança;
revisão do código por IA utilizando os padrões definidos pelo projeto;
correção ou avaliação dos apontamentos encontrados;
disponibilização do pull request para revisão humana;
revisão, aprovação e merge;
observação do comportamento após a entrega.

Esse fluxo também cria uma separação mais clara entre o que esperamos da automação e o que esperamos das pessoas envolvidas no processo.

Ferramentas automatizadas são particularmente adequadas para verificações repetitivas, comparação com padrões conhecidos e análise sistemática de grandes quantidades de código. Desenvolvedores, por outro lado, continuam sendo fundamentais para avaliar decisões que dependem de contexto, experiência, conhecimento do produto e compreensão das consequências de longo prazo de uma implementação.

Small batches sem controle de WIP não resolvem o problema

Existe uma ressalva importante nessa proposta.

Dividir uma tarefa em cinco pull requests menores não necessariamente melhora o fluxo se os cinco forem produzidos imediatamente e colocados simultaneamente na fila de revisão. Nesse cenário, apenas substituímos uma alteração grande por várias alterações menores acumuladas no mesmo ponto do processo.

Por esse motivo, acredito que a discussão sobre small batches precisa estar associada ao controle de WIP.

Se o desenvolvimento assistido por IA permite produzir código mais rapidamente do que conseguimos revisar, talvez não seja desejável utilizar toda essa capacidade simplesmente para iniciar mais trabalho.

Uma alternativa seria utilizar parte desse ganho de produtividade para concluir completamente uma quantidade menor de mudanças antes de iniciar outras.

Isso pode significar que um desenvolvedor, enquanto aguarda uma revisão, dedique tempo à melhoria de testes, investigação de outros aspectos da mesma tarefa, documentação ou revisão de PRs de outros membros do time, em vez de iniciar imediatamente diversas novas implementações.

Nesse modelo, o objetivo não seria maximizar a utilização individual de cada desenvolvedor, mas melhorar o fluxo do trabalho através do sistema como um todo.

Como validar se essa abordagem realmente funciona

Apesar de essas práticas possuírem fundamentos conhecidos na engenharia de software, acredito que seria precipitado assumir que essa combinação necessariamente funcionará para qualquer equipe ou projeto.

O impacto da codificação assistida por IA ainda está sendo compreendido, e diferentes times possuem características bastante distintas em relação a tamanho, arquitetura, processo de revisão e frequência de deploy.

Por isso, talvez a melhor forma de avaliar essa proposta seja tratá-la como um experimento.

Durante algumas semanas, uma equipe poderia estabelecer algumas regras simples: limitar o tamanho das mudanças, controlar a quantidade de trabalho simultaneamente em revisão, manter pull requests inicialmente como draft e executar as verificações automatizadas e revisões por IA antes de solicitar uma revisão humana.

A partir daí, poderíamos observar algumas métricas, como tempo entre abertura do PR e primeira revisão, tempo total até o merge, tamanho médio das alterações, quantidade de ciclos de revisão, número de problemas encontrados antes da revisão humana, quantidade de problemas encontrados depois do merge e tempo dedicado pelos desenvolvedores a code review.

Também seria importante coletar informações qualitativas. Um processo pode apresentar métricas melhores e, ainda assim, aumentar a frustração dos desenvolvedores ou criar burocracia desnecessária. Perguntas simples sobre a facilidade de compreender os PRs, qualidade dos comentários automatizados e percepção de carga de revisão ajudariam a complementar os números.

O que estamos tentando otimizar?

Talvez uma das discussões mais importantes trazidas pela adoção de IA seja justamente a definição do que entendemos como produtividade no desenvolvimento de software.

Se avaliarmos produtividade principalmente pela quantidade de código produzido ou pelo número de tarefas implementadas, ferramentas de IA provavelmente apresentarão ganhos expressivos. Entretanto, essas métricas representam apenas uma parte do processo necessário para transformar uma necessidade de produto em software funcionando de maneira confiável em produção.

Uma tarefa implementada, mas aguardando revisão durante vários dias, ainda representa trabalho em andamento. Da mesma forma, uma grande quantidade de código produzida rapidamente não representa necessariamente uma melhoria se aumentar o custo de revisão, introduzir regressões ou exigir diversas rodadas de correção posteriormente.

Talvez seja mais útil observar o tempo necessário para que uma mudança percorra todo o fluxo, desde o início da implementação até sua integração e disponibilização, considerando também a qualidade obtida nesse processo.

Nesse cenário, a principal oportunidade oferecida pela IA não estaria apenas em escrever código mais rapidamente. Ela também pode ser utilizada para antecipar verificações, documentar decisões, aumentar a cobertura de testes e reduzir o trabalho repetitivo realizado durante revisões.

Considerações finais

O desenvolvimento assistido por IA está aumentando a capacidade de implementação das equipes, mas esse aumento não necessariamente ocorre na mesma proporção em todas as etapas do processo de engenharia. Revisão, validação, compreensão do impacto das mudanças e tomada de decisões continuam exigindo atenção e contexto.

Por isso, acredito que existe espaço para experimentar processos que combinem desenvolvimento em pequenos batches, controle de WIP, automação das verificações objetivas e revisão assistida por IA antes da revisão humana.

A intenção não é criar mais etapas burocráticas nem estabelecer que toda alteração precise passar pelo mesmo conjunto de verificações. Pelo contrário, um bom processo deveria ser capaz de selecionar os critérios relevantes de acordo com o tipo e o risco da mudança.

O resultado que buscamos também não deveria ser simplesmente produzir mais pull requests ou aumentar a quantidade de código entregue por desenvolvedor. O objetivo seria reduzir o tempo e o esforço necessários para que uma alteração percorra o processo de desenvolvimento com um nível adequado de confiança.

Essa é a hipótese que considero mais interessante para discussão: se a IA está aumentando significativamente nossa capacidade de produzir software, como devemos adaptar o restante do processo de engenharia para que esse ganho seja convertido em entregas melhores, e não apenas em mais trabalho aguardando revisão?

A resposta provavelmente dependerá de cada equipe. Justamente por isso, acredito que vale experimentar, medir os resultados e compartilhar o que funcionar — e também o que não funcionar.

Referências

DORA — Working in small batches
https://dora.dev/capabilities/working-in-small-batches/

GitHub Docs — Use GitHub Copilot code review across the pull request lifecycle
https://docs.github.com/en/copilot/tutorials/use-copilot-code-review-across-the-pull-request-lifecycle

Entity, DTO, Repository, Service… afinal, quem faz o quê?

Vitor Fábio — Mon, 23 Feb 2026 12:58:58 +0000

Prefácio

Em algum momento da sua jornada como desenvolvedor, você já se perguntou em qual camada deveria colocar a conexão com o banco, se a regra de negócio pertence ao Service ou à Entity, se é aceitável enviar e-mails diretamente do Controller ou se o DTO realmente é necessário quando a Entity já possui os campos?

Se essas dúvidas já passaram pela sua cabeça, saiba que isso é mais comum do que parece.

À medida que os projetos deixam de ser apenas CRUDs simples e começam a crescer, a organização do código deixa de ser um detalhe e passa a ser uma preocupação concreta. Misturar responsabilidades pode até funcionar no início, mas, com o tempo, o acoplamento aumenta, as mudanças se tornam mais delicadas e o código passa a exigir um esforço desproporcional para algo que deveria ser simples.

Este artigo nasce justamente dessa inquietação.

A proposta é desmistificar alguns dos principais termos que aparecem quando falamos em arquitetura orientada a objetos, Entity, Model, DAO, Repository, DTO, Service, Controller e Action, e esclarecer o papel de cada um dentro de um projeto.

Mais do que decorar nomes ou seguir padrões por tendência, o objetivo é compreender responsabilidades.

Arquitetura de software não é sinônimo de complexidade. É, acima de tudo, separação consciente de responsabilidades.

De onde vêm esses conceitos?

Essas ideias não surgiram por acaso. Elas são influenciadas por princípios discutidos em livros como Clean Code e Clean Architecture, de Robert C. Martin, e Domain-Driven Design, de Eric Evans.

Essas obras não apresentam receitas prontas nem estruturas rígidas. O que propõem são princípios como separação de responsabilidades, baixo acoplamento, alta coesão e inversão de dependência.

Com o tempo, esses fundamentos passaram a influenciar frameworks, arquiteturas modernas e projetos reais. O problema é que, muitas vezes, aprendemos o “como usar” antes de compreender o “por que usar”.

É exatamente nesse ponto que a confusão começa.

2. Um ponto de partida: o Controller não é dono da regra

Vamos partir de uma premissa simples: o Controller existe para lidar com o mundo externo.

Em uma API HTTP, isso significa receber requisições, validar dados de entrada quanto a formato, tipos e obrigatoriedade, converter essas informações para o formato interno da aplicação, delegar a execução da regra de negócio e, por fim, retornar uma resposta HTTP adequada.

Todas essas responsabilidades estão relacionadas à comunicação. O Controller traduz o mundo externo para algo que a aplicação entende e depois traduz a resposta de volta.

O que ele não deveria fazer é tomar decisões de negócio, conversar diretamente com o banco, enviar e-mails, consumir APIs externas, executar regras complexas ou controlar transações.

Quando o Controller passa a assumir esse tipo de responsabilidade, deixa de ser apenas uma camada de entrada e começa a concentrar decisões que não lhe pertencem. As consequências tendem a ser previsíveis: alto acoplamento, dificuldade de testes, maior complexidade para evoluir o código e repetição de lógica em diferentes endpoints.

O sistema pode continuar funcionando, mas perde organização. E sem organização, a manutenção inevitavelmente se torna mais custosa.

Sobre validação

Ao falar em validação no Controller, é importante fazer uma distinção.

Nem toda validação é igual. Existe a validação estrutural, responsável por verificar formato, tipagem e campos obrigatórios, e existe a validação de regra de negócio, que envolve regras do domínio, como e-mail já cadastrado, saldo insuficiente ou limite excedido.

A validação estrutural faz sentido na camada de entrada, pois está ligada à integridade dos dados recebidos. Já a validação de regra pertence à camada de aplicação ou ao próprio domínio.

Em alguns frameworks, como o Laravel, essas responsabilidades podem parecer misturadas. Por isso, essa distinção é relevante: quando não diferenciamos esses tipos de validação, o Controller acaba acumulando responsabilidades sem perceber.

Se o Controller não é responsável pela regra de negócio, surge então uma pergunta natural: onde essa regra deve ficar?

É nesse momento que a separação de camadas deixa de ser apenas teoria e passa a fazer sentido na prática. A intenção não é adicionar complexidade desnecessária, mas distribuir responsabilidades de maneira clara e coerente.

Camadas

DTO — O contrato com o mundo externo

Se o Controller interage com o mundo externo, ele precisa de uma estrutura que organize essa troca de dados. É aqui que entra o DTO (Data Transfer Object).

O DTO não representa o domínio da aplicação; ele representa o contrato de entrada ou saída. Um CreateUserRequest, por exemplo, pode conter apenas nome e e-mail, exatamente como esperado pela API.

Ele não contém regra de negócio, não conhece banco de dados e não depende de infraestrutura. Sua função é transportar dados entre camadas.

Nesse ponto, surge uma dúvida comum: se a Entity já possui esses campos, por que criar DTO?

Porque o domínio não deve depender do formato externo da aplicação. O DTO protege a Entity de mudanças na API, evita a exposição de campos sensíveis e impede que detalhes internos vazem para fora. Ele funciona como uma barreira entre o mundo externo e o núcleo da aplicação.

Service — Onde a decisão acontece

Se o Controller não deve tomar decisões, alguém precisa assumir essa responsabilidade.

Essa função costuma ficar no Service — abordagem mais comum — ou, em arquiteturas orientadas a caso de uso, em uma Action.

O Service é responsável por orquestrar o fluxo da aplicação. É nele que a regra de negócio acontece. Pode aplicar validações de domínio, consultar repositórios, criar ou modificar entidades, coordenar efeitos colaterais como envio de e-mails ou integração com APIs externas e controlar transações quando necessário.

Diferente do Controller, o Service não sabe nada sobre HTTP. Ele não sabe se a aplicação é uma API, um CLI ou um job agendado. Ele simplesmente executa um fluxo de negócio.

Essa separação traz um benefício importante: a regra deixa de depender da forma como o sistema é acessado. Se amanhã for necessário expor o mesmo fluxo por meio de fila, CLI ou outro endpoint, o Service continuará o mesmo, o que contribui para escalabilidade e reaproveitamento.

Vale uma observação: Service não deve existir apenas para repassar chamadas. Se ele apenas invoca repository.save() sem tomar decisões, talvez não esteja agregando valor real ao fluxo.

Entity — O coração do domínio

Se o Service decide o fluxo, a Entity representa o que o sistema é.

Ela não é apenas uma estrutura de dados com getters e setters, mas a representação de um conceito do domínio. Um Usuário, um Pedido ou uma Fatura são exemplos claros de entidades.

Uma Entity possui identidade. Mesmo que seus atributos mudem, ela continua sendo a mesma entidade dentro do sistema.

Dependendo do nível de maturidade arquitetural, pode conter regras relacionadas à sua própria consistência. Um Pedido pode impedir que seja finalizado duas vezes; uma Conta pode impedir saque se o saldo for insuficiente; um Usuário pode normalizar seu próprio e-mail ao ser criado.

Essas regras dizem respeito à coerência interna do objeto, não ao fluxo da aplicação.

A Entity não precisa conhecer banco de dados, HTTP, frameworks, envio de e-mails ou execução de queries. Ela representa o domínio, não a infraestrutura. Quando passa a depender de detalhes externos, o domínio perde independência e se torna acoplado à tecnologia.

Inicialmente, tive bastante confusão entre Entity e DTO. De maneira simples, posso dizer que a Entity está mais próxima do domínio e, muitas vezes, do mapeamento com o banco ou ORM, enquanto o DTO está relacionado à transferência de dados entre camadas. Isso significa que é perfeitamente normal existir Entities e DTOs no mesmo projeto.

Repository — Abstração de persistência

Se a Entity representa o domínio e o Service concentra a decisão, alguém precisa cuidar da persistência.

O Repository cumpre esse papel. Ele representa um conjunto de operações relacionadas a uma entidade e se comunica na linguagem do domínio, não na linguagem da tabela.

Em vez de pensar em “tabela users”, o Repository pensa em “Usuários”. Pode oferecer operações como salvar um usuário, buscar por e-mail, listar ativos ou remover por id.

O ponto central é que o Service não deve conhecer os detalhes da persistência. Ele não precisa saber se está utilizando JPA, SQL puro, MongoDB ou qualquer outra tecnologia. Interage apenas com um contrato.

Essa separação permite trocar a tecnologia de armazenamento, testar a regra de negócio de forma isolada e reduzir o acoplamento com a infraestrutura.

O Repository não executa regra de negócio; ele executa persistência.

DAO — O aspecto mais técnico da persistência

DAO (Data Access Object) é um padrão mais antigo e mais técnico.

Enquanto o Repository é orientado ao domínio, o DAO costuma ser mais voltado à infraestrutura. Ele encapsula operações diretas com o banco, como execução de queries, mapeamento de resultados, controle de conexão e manipulação de SQL específico.

Em projetos simples, DAO e Repository podem acabar desempenhando papéis muito semelhantes. Conceitualmente, porém, existe uma diferença sutil: o DAO fala a linguagem do banco; o Repository fala a linguagem do domínio.

Essa distinção tende a ficar mais evidente conforme o sistema cresce.

Reflexões

À medida que aprofundamos a separação de responsabilidades, é natural que surjam variações desses mesmos conceitos em arquiteturas mais estruturadas.

Em vez de concentrar várias responsabilidades dentro de um único Service com muitos métodos, algumas abordagens preferem trabalhar com Use Cases ou Actions, em que cada fluxo de negócio ganha sua própria classe, como CreateUser ou CancelOrder. Isso tende a reduzir o tamanho das classes e deixa cada comportamento mais explícito, quase como uma narrativa do que o sistema faz.

Outro conceito que costuma aparecer nesse contexto é o Mapper, responsável por converter DTOs em Entities e vice-versa. Em projetos menores, essa conversão pode permanecer dentro do Service sem grandes problemas. Em sistemas maiores, porém, centralizar essa responsabilidade ajuda a evitar repetição e torna o código mais organizado.

Também existe o Domain Service, bastante discutido em Domain-Driven Design. Ele entra em cena quando uma regra não pertence claramente a uma única entidade. É um tema que merece um aprofundamento próprio, mas vale a menção para mostrar que a separação de responsabilidades não é estática, ela pode evoluir conforme o domínio se torna mais complexo.

No fundo, o que estamos fazendo ao organizar essas camadas é aproximar o código do domínio do negócio. E essa é justamente a essência do DDD: estruturar o sistema em torno do que ele representa, e não da tecnologia que o sustenta.

Arquitetura é preparação para mudança

Nem todo projeto precisa nascer com todas essas camadas bem definidas. Em aplicações muito pequenas ou sistemas que dificilmente irão evoluir, criar múltiplas abstrações pode gerar mais complexidade do que benefício.

Por outro lado, quando o sistema começa a crescer, novas regras surgem, integrações são adicionadas e diferentes pontos de entrada aparecem, a ausência de separação passa a cobrar um preço.

Arquitetura não é formalidade. É preparação para mudança.

É comum que um sistema comece simples e, com o tempo, passe por refatorações que separem responsabilidades que antes estavam misturadas. Isso não significa que o projeto estava errado no início; significa que ele amadureceu.

O próprio Clean Code reforça essa ideia de melhoria contínua por meio de refatoração. Separar camadas pode ser apenas mais um passo nessa direção.

Arquitetura também evolui

Existe a ideia de que decisões arquiteturais precisam ser perfeitas desde o primeiro dia. Na prática, isso raramente acontece.

Projetos podem adotar separação de camadas mesmo após anos em produção, e essa reorganização costuma acontecer de forma gradual: primeiro extraindo regras do Controller, depois isolando persistência, depois introduzindo contratos mais claros entre as partes.

Quando essa organização começa a se repetir em diferentes áreas do sistema, surge algo maior do que apenas camadas. Surgem módulos organizados por contexto, por domínio, por significado.

Nesse momento, a arquitetura deixa de ser apenas uma divisão técnica e passa a refletir o próprio negócio. E é justamente aí que conceitos do Domain-Driven Design começam a fazer mais sentido.

Conclusão

No fim das contas, esses padrões não existem para tornar o código mais sofisticado nem para atender a uma formalidade arquitetural. Eles existem para deixar claro quem faz o quê e para manter o domínio no centro da aplicação.

Quando essa clareza aparece, o sistema deixa de ser apenas funcional e passa a ser sustentável. Sustentável no sentido de poder crescer, mudar e evoluir sem que cada nova alteração gere insegurança ou retrabalho excessivo.

Arquitetura não é sobre criar barreiras artificiais. É sobre dar espaço para que o domínio respire e para que o sistema acompanhe a complexidade do mundo real sem perder organização.

Encerramento

Quando comecei a estudar esses conceitos, a dúvida sempre era muito direta: “em qual camada eu coloco isso?”. Com o tempo, percebi que a pergunta mais importante não era onde colocar o código, mas se aquela responsabilidade realmente pertencia ali.

Essa mudança de perspectiva transforma a forma como enxergamos arquitetura. Ela deixa de ser um conjunto de nomes complexos e passa a ser um exercício constante de organização.

Nem todo projeto precisa de todas as camadas desde o primeiro dia. Mas todo projeto que cresce precisa, em algum momento, organizar suas responsabilidades.

Se este texto conseguir tornar essa distinção um pouco mais clara, então ele já cumpriu seu papel.

Entity, DTO, Repository, Service… afinal, quem faz o quê?

Vitor Fábio — Mon, 23 Feb 2026 11:00:00 +0000

Prefácio

Se essas dúvidas já passaram pela sua cabeça, saiba que isso é mais comum do que parece.

Este artigo nasce justamente dessa inquietação.

A proposta é desmistificar alguns dos principais termos que aparecem quando falamos em arquitetura orientada a objetos — Entity, Model, DAO, Repository, DTO, Service, Controller e Action — e esclarecer o papel de cada um dentro de um projeto.

Mais do que decorar nomes ou seguir padrões por tendência, o objetivo é compreender responsabilidades.

Arquitetura de software não é sinônimo de complexidade. É, acima de tudo, separação consciente de responsabilidades.

De onde vêm esses conceitos?

É exatamente nesse ponto que a confusão começa.

2. Um ponto de partida: o Controller não é dono da regra

Vamos partir de uma premissa simples: o Controller existe para lidar com o mundo externo.

Todas essas responsabilidades estão relacionadas à comunicação. O Controller traduz o mundo externo para algo que a aplicação entende e depois traduz a resposta de volta.

O que ele não deveria fazer é tomar decisões de negócio, conversar diretamente com o banco, enviar e-mails, consumir APIs externas, executar regras complexas ou controlar transações.

O sistema pode continuar funcionando, mas perde organização. E sem organização, a manutenção inevitavelmente se torna mais custosa.

Sobre validação

Ao falar em validação no Controller, é importante fazer uma distinção.

A validação estrutural faz sentido na camada de entrada, pois está ligada à integridade dos dados recebidos. Já a validação de regra pertence à camada de aplicação ou ao próprio domínio.

Se o Controller não é responsável pela regra de negócio, surge então uma pergunta natural: onde essa regra deve ficar?

Camadas

DTO — O contrato com o mundo externo

Se o Controller interage com o mundo externo, ele precisa de uma estrutura que organize essa troca de dados. É aqui que entra o DTO (Data Transfer Object).

Ele não contém regra de negócio, não conhece banco de dados e não depende de infraestrutura. Sua função é transportar dados entre camadas.

Nesse ponto, surge uma dúvida comum: se a Entity já possui esses campos, por que criar DTO?

Service — Onde a decisão acontece

Se o Controller não deve tomar decisões, alguém precisa assumir essa responsabilidade.

Essa função costuma ficar no Service — abordagem mais comum — ou, em arquiteturas orientadas a caso de uso, em uma Action.

Diferente do Controller, o Service não sabe nada sobre HTTP. Ele não sabe se a aplicação é uma API, um CLI ou um job agendado. Ele simplesmente executa um fluxo de negócio.

Vale uma observação: Service não deve existir apenas para repassar chamadas. Se ele apenas invoca repository.save() sem tomar decisões, talvez não esteja agregando valor real ao fluxo.

Entity — O coração do domínio

Se o Service decide o fluxo, a Entity representa o que o sistema é.

Ela não é apenas uma estrutura de dados com getters e setters, mas a representação de um conceito do domínio. Um Usuário, um Pedido ou uma Fatura são exemplos claros de entidades.

Uma Entity possui identidade. Mesmo que seus atributos mudem, ela continua sendo a mesma entidade dentro do sistema.

Essas regras dizem respeito à coerência interna do objeto, não ao fluxo da aplicação.

Repository — Abstração de persistência

Se a Entity representa o domínio e o Service concentra a decisão, alguém precisa cuidar da persistência.

O Repository cumpre esse papel. Ele representa um conjunto de operações relacionadas a uma entidade e se comunica na linguagem do domínio, não na linguagem da tabela.

Em vez de pensar em “tabela users”, o Repository pensa em “Usuários”. Pode oferecer operações como salvar um usuário, buscar por e-mail, listar ativos ou remover por id.

Essa separação permite trocar a tecnologia de armazenamento, testar a regra de negócio de forma isolada e reduzir o acoplamento com a infraestrutura.

O Repository não executa regra de negócio; ele executa persistência.

DAO — O aspecto mais técnico da persistência

DAO (Data Access Object) é um padrão mais antigo e mais técnico.

Essa distinção tende a ficar mais evidente conforme o sistema cresce.

Conclusões

À medida que aprofundamos a separação de responsabilidades, é comum encontrar variações desses conceitos em arquiteturas mais estruturadas.

Em vez de um Service com vários métodos, algumas abordagens adotam o conceito de Use Case ou Action, em que cada fluxo de negócio é representado por uma classe específica, como CreateUser ou CancelOrder. Isso reduz o tamanho das classes e torna cada comportamento mais explícito.

Outro conceito recorrente é o Mapper, responsável por converter DTOs em Entities e vice-versa. Em projetos menores, essa conversão pode permanecer no Service sem grandes problemas; em sistemas maiores, centralizá-la tende a melhorar a organização e evitar repetições.

Também existe o Domain Service, discutido em Domain-Driven Design, utilizado quando uma regra não pertence claramente a uma única entidade. É um tema que merece aprofundamento próprio, mas sua menção ajuda a mostrar que a separação de responsabilidades pode evoluir conforme o domínio se torna mais complexo.

Nem sempre precisamos de todas essas camadas. Em projetos muito pequenos ou aplicações que dificilmente irão evoluir, criar múltiplas camadas pode gerar mais complexidade do que benefício.

Por outro lado, quando o sistema começa a crescer, novas regras surgem, integrações são adicionadas e diferentes pontos de entrada aparecem, a ausência de separação passa a cobrar um preço alto.

Arquitetura não é formalidade; é preparação para mudança.

É comum que um sistema comece simples e, com o tempo, passe por refatorações que separem responsabilidades antes misturadas. Isso não significa que o projeto estava errado no início, mas que ele amadureceu.

O próprio Clean Code reforça a ideia de melhoria contínua por meio de refatoração. Separar camadas pode ser uma dessas melhorias.

Muitos desenvolvedores acreditam que decisões arquiteturais precisam ser perfeitas desde o primeiro dia. Na prática, raramente isso acontece. Projetos podem adotar separação de camadas mesmo após anos em produção, de forma gradual: primeiro extraindo regras do Controller, depois isolando persistência e, por fim, introduzindo contratos mais claros.

Arquitetura também evolui.

E essa evolução nos leva a uma discussão importante: como essas camadas se comportam quando utilizamos ORM, Active Record ou SQL puro?

Dependendo da tecnologia escolhida, algumas camadas podem assumir papéis diferentes. Em frameworks que utilizam Active Record, como o Eloquent do Laravel, a própria classe Model costuma acumular responsabilidades de entidade e persistência. Isso simplifica o desenvolvimento inicial, mas pode misturar domínio e infraestrutura.

Em arquiteturas baseadas em ORM mais tradicionais, como JPA no ecossistema Java, é comum que as Entities sejam mapeadas para o banco por meio de anotações, enquanto o acesso aos dados ocorre via Repository.

Já em projetos que utilizam SQL puro, sem ORM, padrões como DAO fazem ainda mais sentido, pois encapsulam queries, mapeamento de resultados e controle de conexão.

A tecnologia influencia a forma como esses padrões são aplicados, mas os princípios de separação de responsabilidades permanecem os mesmos.

Independentemente de usar ORM ou SQL direto, a pergunta continua válida: quem decide, quem representa o domínio e quem persiste?

Encerramento

Essa mudança de perspectiva transforma a forma como enxergamos arquitetura. Ela deixa de ser um conjunto de nomes complexos e passa a ser um exercício constante de organização.

Nem todo projeto precisa de todas as camadas desde o primeiro dia. Mas todo projeto que cresce precisa, em algum momento, organizar suas responsabilidades.

Se este texto conseguir tornar essa distinção um pouco mais clara, então ele já cumpriu seu papel.

Padronizando o Caos: Minha jornada com Dotfiles

Vitor Fábio — Wed, 30 Apr 2025 15:30:00 +0000

Manter consistência em ambientes de desenvolvimento sempre foi um desafio para mim. Cada novo sistema Linux instalado, seja no desktop pessoal ou em servidores, exigia uma nova "dança" de configurações de shell, editores, atalhos, temas e programas. Foi então que decidi iniciar meu próprio repositório de dotfiles: svitorz/dotfiles.

A ideia

Desde o início da minha jornada como desenvolvedor, sempre me interessei por sistemas Linux, e claro, pelo terminal. Mas a minha inquietação com Linux foi tanta, que troquei de distribuição várias vezes, passando por Debian, Ubuntu 22.04, Ubuntu 24.04, Mint, Pop!_OS e finalmente, a distro que utilizo até hoje: o Arch Linux. Entretanto, entre todas essas trocas de sistema, sempre havia algo muito trabalhoso e repetitivo que causava estresse durante o processo: a configuração de ambiente.

O início

Certa vez, aleatoriamente, caí em um repositório de um desconhecido que falava sobre como mantinha suas "personal files". De cara, não entendi exatamente a que ele se referia e, vendo o repositório, mal sabia do que se tratava. Foi quando, em uma busca rápida, entendi que se tratavam de arquivos de configuração pessoais. Ou seja, cada usuário poderia manter os seus da forma que bem desejasse, de acordo com suas ambições dentro da sua distro Linux. E mais: isso tinha o poder de padronizar todas as ferramentas utilizadas no dia a dia, independente de sistema, máquina ou projeto.

Como mantenho minhas dotfiles?

Para cada aplicação, ferramenta ou framework que utilizo, mantenho uma pasta única e separada para facilitar a busca e interpretação dos comandos. Também mantenho todos os arquivos na linguagem padrão da aplicação: seja Shell Script, no caso do .zshrc, ou Lua, no caso dos arquivos de configuração do Neovim.

Utilização de ShellScript para agilizar o processo

Dentro da pasta /home/user/ da minha máquina, há um arquivo chamado savedotfiles, que faz uma cópia de todos os arquivos de configuração para o diretório dotfiles, que é onde está o repositório. Após isso, o mesmo shell script roda o comando:

git add .

Facilitando para que eu apenas faça o commit e o push.

Uso do Git para gerenciar o repositório

Utilizo o Git de forma convencional, mas com alguns cuidados:

Commits frequentes: toda pequena melhoria ou novo ajuste é versionado.
Mensagens claras: cada commit explica o motivo daquela alteração.
Branches de experimentação: quando quero testar uma nova tool ou mudança, crio uma branch separada.
Backups regulares: mantenho um clone do repositório em mais de um local.

Atualmente, o repositório é público para que outros possam ver como montei meu ambiente, pegar ideias ou sugerir melhorias.

Considerações finais

Manter um repositório de dotfiles mudou a forma como lido com ambientes de trabalho. Se você ainda não começou o seu, recomendo demais: é um exercício de organização, automação e consistência.

Se quiser dar uma olhada ou se inspirar, o repositório está aqui: github.com/svitorz/dotfiles

E você? Como gerencia seu ambiente de desenvolvimento? Vamos conversar nos comentários!

Tutorial para criação de projetos com Ruby on Rails (sem Ruby localmente)

Vitor Fábio — Tue, 31 Dec 2024 01:51:07 +0000

Primeiramente, crie uma um arquivo chamado "Dockerfile", então insira nele o seguinte conteúdo.

Dockerfile:

# Use uma imagem oficial do Ruby
FROM ruby:3.2

# Instale dependências do sistema
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs yarn

# Defina o diretório de trabalho
WORKDIR /app

# Instale bundler e Rails
RUN gem install bundler rails

# Copie o Gemfile e Gemfile.lock (se existir)
COPY Gemfile Gemfile.lock /app/

# Instale as gems
RUN bundle install

# Copie o restante da aplicação para dentro do container
COPY . /app

Insira no seu terminal:

$ docker build -t rails-crud .

Após isso, você já poderá criar seu projeto. Entre no diretório que deseja manter seu projeto, e insira no terminal:

$ docker run -it --rm -v $(pwd):/app -w /app rails-crud rails new nome-do-projeto