DEV Community: Gabriel Batista

Aplicando DDD: Antes do tático, vem o domínio

Gabriel Batista — Tue, 02 Jun 2026 16:25:47 +0000

Introdução

Quando comecei a estudar DDD, minha atenção foi quase toda para a parte tática. Queria entender como organizar o código, criar uma boa estrutura de pastas e aplicar aqueles padrões que apareciam em artigos, vídeos e repositórios no GitHub: aggregate, value object, domain event, repository, domain service, CQRS, event sourcing e por aí vai.

Na minha cabeça, aplicar DDD era muito sobre conseguir montar uma arquitetura bonita, com as responsabilidades bem separadas e nomes que pareciam fazer sentido. Enquanto isso, alguns conceitos como linguagem ubíqua, bounded context, context map... acabavam ficando em segundo plano. Eu até sabia que eles existiam, mas pareciam uma etapa mais abstrata, teórica demais, antes da parte que realmente me interessava: escrever código.

Depois de alguns projetos de exemplo, comecei a perceber um padrão. No começo tudo parecia organizado, mas conforme o domínio crescia, as decisões começavam a ficar confusas. Precisava combinar vários agregados, criava serviços de domínio para resolver regras que ainda não entendia bem, movia responsabilidades de um lado para o outro e tentava encaixar mais um padrão que parecesse resolver a situação.

O problema é que eu ainda não sabia exatamente o que queria construir. Seguia uma lista de padrões sem entender, de fato, o motivo por trás de cada um. O resultado era um software tecnicamente organizado, mas pouco conectado com a realidade do negócio.

Este artigo abre uma série de textos inspirada nas discussões do clube do livro da Tech Leads Club. O livro que estamos lendo é Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy, e a proposta aqui é usar essa leitura como ponto de partida para organizar meu entendimento e aplicar essas ideias na construção de um sistema.

Neste primeiro texto, vamos começar justamente por onde eu deveria ter começado: o DDD estratégico. Antes de falar sobre código, vamos olhar para domínio e os subdomínios usando como exemplo o domínio de Turismo.

DDD estratégico

A ideia do DDD estratégico não é começar desenhando pastas, classes ou camadas da aplicação. Antes disso, precisamos entender em que domínio estamos trabalhando, quais partes desse domínio são mais importantes para o negócio, quais problemas precisam ser resolvidos e quais conceitos fazem sentido para as pessoas que vivem aquele contexto no dia a dia.

Essa etapa ajuda a responder perguntas como:

Qual é o problema principal que o software precisa resolver?
Onde está o diferencial do negócio?
Quais partes do sistema merecem mais investimento de modelagem?
Onde um mesmo termo pode ter significados diferentes dependendo do contexto?

Conceitos fundamentais

O primeiro é domínio. No DDD, domínio é a área de atividade que o software precisa compreender. É o pedaço da realidade em que a empresa atua e onde o sistema precisa fazer sentido.

O segundo é subdomínio. Um subdomínio é uma parte menor e mais específica dentro desse domínio maior. Ele representa um recorte do problema de negócio.

O terceiro é o especialista de domínio. O especialista de domínio é a pessoa que conhece o problema de verdade. É quem entende as regras, as exceções, os conflitos, os termos usados na operação e o que realmente importa para o negócio. Nem sempre essa pessoa é alguém de tecnologia. Muitas vezes ela está em áreas como atendimento, operações, vendas, financeiro, produto ou gestão.

Disclaimer: como este artigo é um exercício, eu mesmo vou assumir o papel de especialista de domínio :)

O que é domínio?

Quando falamos de domínio no DDD, estamos falando da área da realidade que precisa ser entendida para que o sistema cumpra seu papel. Se estamos falando de um e-commerce, o domínio está ligado à operação de venda. Se estamos falando de uma plataforma de streaming, o domínio está ligado à distribuição e ao consumo de mídia.

No nosso caso, dizer apenas que o domínio é Turismo ainda é abstrato demais. É parecido com dizer que o domínio da Uber é transporte urbano. Não está errado, mas ainda não ajuda muito a entender o problema de verdade.

Então precisamos refinar. O nosso recorte aqui será Turismo de Experiência. A ideia é oferecer uma experiência completa, facilitando a escolha de hospedagens, guias, roteiros e experiências locais. Nosso software fica responsável por fazer o melhor match entre turistas, guias e rotas com base no perfil e nos gostos do cliente, tornando o processo da viagem algo mais simples.

Percebe que aqui já começa a aparecer uma pista importante? O sistema não quer só listar opções. Ele quer montar uma experiência personalizada na hora de escolher sua viagem. E isso ajuda a entender onde talvez esteja o diferencial do negócio.

Onde entram os subdomínios?

Sabemos qual é o domínio e já temos uma noção melhor do que queremos fazer. A próxima pergunta é: o que realmente diferencia nossa empresa? O que fazemos com maestria que pode virar vantagem competitiva?

Para responder isso, precisamos quebrar um pouco mais o problema. É aí que entram os subdomínios.

Um jeito simples de pensar é assim:

domínio é o problema maior que a empresa quer resolver
subdomínio é uma parte coerente desse problema

No nosso exemplo, o problema que a parte de gestão dos roteiros resolve é diferente do problema de gerenciar parceiros. O problema de reservas é diferente do problema de pagamentos. Tudo está dentro do mesmo domínio, mas não representa a mesma coisa.

Uma heurística boa aqui é olhar para conjuntos coerentes de casos de uso: se os mesmos atores, os mesmos dados e as mesmas regras aparecem juntos com frequência, existe um bom sinal de que ali temos um subdomínio separado.

Subdomínios

No nosso contexto, em que estamos desenvolvendo um software novo, a gente ainda vai descobrir onde estão esses subdomínios. Em uma empresa já estabelecida, isso costuma aparecer de forma mais natural na própria operação: atendimento, marketing, financeiro, operações e por aí vai.

Depois de mapear os subdomínios, precisamos classificá-los entre Core, Generic e Supporting.

Tipo	O que representa	Estratégia
Core	Parte mais valiosa e mais ligada ao diferencial do negócio	Mais investimento, mais cuidado e modelagem mais rica
Generic	Coisas que quase toda empresa precisa	Comprar, integrar ou resolver da forma mais simples possível
Supporting	Partes importantes, mas que não são o diferencial principal	Construir de forma objetiva, sem sofisticar demais

Quando falamos de Core, estamos nos referindo à parte principal do software, onde mora a vantagem competitiva. É onde faz sentido colocar mais energia, mais atenção e as melhores cabeças da equipe.

O Generic é aquilo que todo mundo faz. Algo que a gente até pode desenvolver, mas que muitas vezes faz mais sentido contratar ou integrar. Exemplos clássicos são gateways de pagamento, OAuth, autenticação e envio de e-mails.

Por fim, temos o Supporting, que apoia o negócio principal mas não é o centro dele. Normalmente aqui aparecem regras importantes, só que mais simples, sem exigir o mesmo nível de modelagem que o core.

Também vale um detalhe: isso não é regra absoluta. Auth e pagamentos normalmente entram como genéricos, mas, em alguns contextos, uma empresa pode escolher manter isso internamente por custo, escala, compliance ou estratégia. DDD não manda comprar tudo. DDD manda pensar.

Uma matriz simples para pensar nisso

Aspecto	Core	Generic	Supporting
Vantagem competitiva	Sim	Não	Não
Complexidade	Alta	Pode ser alta, mas comum ao mercado	Baixa a média
Volatilidade	Alta	Geralmente baixa	Baixa a média
Estratégia	Investir forte	Comprar, integrar ou reaproveitar	Resolver sem sofisticar demais
Time	Mais experiente	Pode ser vendor ou solução pronta	Pode evoluir junto com o produto

Os subdomínios do nosso exemplo

Se olharmos para o problema descrito até aqui, uma primeira lista de subdomínios seria algo como:

Curadoria e match de experiências
Gestão de ofertas
Gestão de parceiros
Reserva e disponibilidade
Pagamentos
Identidade e acesso
Notificações

Considerando que o diferencial da nossa empresa está em montar a melhor experiência possível para cada turista, então curadoria e match de experiências provavelmente é o nosso Core Domain.

Uma classificação inicial poderia ficar assim:

Subdomínio	Classificação	Papel no negócio
Curadoria e match de experiências	Core	Encontrar a melhor combinação entre perfil do turista, guia, roteiro e experiência
Gestão de ofertas	Supporting	Organizar roteiros, pacotes, hospedagens e eventos como opções ofertáveis ao turista
Gestão de parceiros	Supporting	Gerenciar guias, anfitriões e outros prestadores, com perfis, especialidades, idiomas e disponibilidade
Reserva e disponibilidade	Supporting	Coordenar consulta de disponibilidade, bloqueio de vagas, confirmação, cancelamento e regras de reserva
Pagamentos	Generic	Cobrança, repasse e confirmação financeira
Identidade e acesso	Generic	Login, identidade e controle de acesso
Notificações	Generic	E-mails, push e mensagens operacionais

Essa classificação ainda pode mudar, porque ela depende da estratégia da empresa. Se amanhã o grande diferencial passar a ser a montagem inteligente de roteiros, Gestão de ofertas pode subir de importância e até se fundir com o core. O objetivo aqui não é congelar o desenho, e sim começar a enxergar onde vale investir nosso esforço.

Conclusão

No próximo artigo vamos continuar refinando nossos subdomínios e falar um pouco sobre linguagem ubíqua.

Como Resolver o Erro DbUpdateConcurrencyException no Entity Framework

Gabriel Batista — Fri, 03 Jan 2025 05:38:52 +0000

Se você estiver gerando seus próprios IDs ao usar Entity Framework e se deparar com um erro de concorrência, essa dica pode te ajudar!

Recentemente, enfrentei um problema interessante ao trabalhar com Entity Framework: um DbUpdateConcurrencyException aparentemente inexplicável ao tentar salvar novas entidades.

A funcionalidade era simples:

Recuperar um Grupo do banco
Adicionar um Membro ao Grupo
Salvar tudo

O código parecia correto, mas sempre recebia:

DbUpdateConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s)

O que acontece?

Esse erro ocorre porque, por padrão, o Entity Framework assume a responsabilidade de gerar e gerenciar os valores das chaves primárias das entidades. Quando você define manualmente um valor para uma chave que normalmente seria gerada, a entidade será rastreada como "Modified" em vez de "Added" e quando uma entidade é marcada como "Modified" em vez de "Added", o EF tenta fazer um UPDATE no banco em vez de um INSERT mas não existe registro para atualizar (é uma nova entidade)

Esse erro ocorre porque, por padrão, o Entity Framework assume a responsabilidade de gerar e gerenciar os valores das chaves primárias das entidades. Quando você define manualmente um valor para uma chave que normalmente seria gerada, a entidade é rastreada como "Modified" em vez de "Added". Como resultado, o EF tenta realizar um UPDATE no banco de dados em vez de um INSERT, mas não existe nenhum registro para atualizar (é uma nova entidade).

A solução? Configure explicitamente que a chave primária não deve ser gerada automaticamente. Isso pode ser feito no Fluent API:

builder.Property(t => t.Id).ValueGeneratedNever();

Ou com data annotations:

[DatabaseGenerated(DatabaseGeneratedOption.None)]
public string Id { get; set; }

Espero que essa dica ajude você a evitar horas de debugging! 😉

Seu Primeiro Pacote NuGet: Um Passo a Passo Prático

Gabriel Batista — Fri, 03 Jan 2025 05:33:35 +0000

Quando você trabalha em diferentes aplicações, é comum se deparar com os mesmos problemas e as mesmas soluções aparecendo de novo e de novo. Isso faz parte do dia a dia de um desenvolvedor, mas pode ser meio cansativo. Agora, imagine se você pudesse pegar esse código repetido, organizar direitinho e usar facilmente em outros projetos. Legal, né? Neste artigo, vamos explorar como fazer isso com o NuGet.

Visão geral:

O NuGet é o gerenciador de pacotes oficial do .NET e ajuda você a empacotar, compartilhar e usar funcionalidades reutilizáveis de forma simples. Com ele, dá para organizar seu código em pacotes, reaproveitá-los em outros projetos e até colaborar de maneira mais prática com outros desenvolvedores.

"Um pacote NuGet é um arquivo ZIP com a extensão .nupkg que contém código compilado (DLLs), arquivos relacionados e um manifesto descritivo com informações como o número da versão. Desenvolvedores criam e publicam pacotes, enquanto consumidores obtêm e utilizam suas funcionalidades. O NuGet gerencia os detalhes intermediários."

Criando um projeto

Antes de começar, crie uma conta no NuGet.org. Isso será necessário para publicar seu pacote.

Crie um projeto do tipo Class Library. No terminal, execute:

dotnet new classlib --name ExamplePackage

Em seguida, abra o projeto em seu editor de preferência. Vamos criar um exemplo simples que converte um objeto em uma string JSON.

Definindo os Metadados

Para criar um pacote, é necessário configurar informações importantes diretamente no arquivo .csproj do projeto. Esse arquivo define os metadados essenciais que identificarão seu pacote no NuGet.

Metadados Obrigatórios:

TargetFramework: Define a versão do .NET que seu projeto utilizará.
PackageId: Um identificador único para seu pacote.
Version: Versão do pacote no formato Major.Minor.Patch (SemVer).
- Major: Alterações que quebram compatibilidade.
- Minor: Novas funcionalidades.
- Patch: Correções de bugs.

Metadados opcionais (não obrigatórios mas fortemente recomendados):

Authors Nome do autor ou autores do pacote.
Description: Uma breve descrição do propósito do pacote.
PackageLicenseExpression: Especifica a licença sob a qual o pacote é distribuído.

Atualize o arquivo .csproj para incluir essas informações:

Compilando o pacote

Com os metadados configurados, é hora de compilar o pacote. No terminal, execute:

dotnet pack --configuration Release

Esse comando criará um arquivo .nupkg na pasta bin/Release.

Testando localmente

Configurando a Fonte Local:

Dentro do projeto, crie uma pasta para os pacotes locais:

mkdir NuGetLocal

Copie o arquivo .nupkg gerado para essa pasta:

cp bin/Release/examplePackage.Convert.1.0.0.nupkg NuGetLocal

Adicione a pasta como uma fonte NuGet:

dotnet nuget add source /caminho/completo/para/NuGetLocal --name NuGetLocal

Consumindo o Pacote no Projeto:

Você pode criar um projeto console para testes:

dotnet new console --name ExamplePackageTest
cd ExamplePackageTest

Use o comando dotnet add package para instalar o pacote:

dotnet add package examplePackage.Convert --version 1.0.0

Testando o Pacote

Abra o arquivo Program.cs do projeto de teste e use o pacote:

Publicação

Após validar seu pacote, é hora de publicá-lo. Acesse sua conta em NuGet.org, vá até o seu perfil e crie uma nova chave.

No terminal, use o comando abaixo para publicar seu pacote no NuGet:

dotnet nuget push bin\Release\examplePackage.Convert.1.0.0.nupkg --api-key SuaAPIkEY --source https://api.nuget.org/v3/index.json

Pronto, se tudo estiver correto após alguns minutos, o pacote estará disponível no NuGet.org.

Conclusão

Agora que você aprendeu a criar, testar e publicar pacotes NuGet, pode começar a criar os seus próprios pacotes para facilitar o seu trabalho e, quem sabe, ajudar outras pessoas com as suas soluções.

Materiais Relacionados e Referências

Como Definir o Contexto Adequado ao Construir um Dockerfile

Gabriel Batista — Thu, 05 Oct 2023 05:15:30 +0000

Quantas vezes você já se deparou com a situação em que tentou criar um Dockerfile e, de repente, ele não conseguia copiar os arquivos para o container? A razão por trás disso pode estar relacionada à escolha do contexto adequado.

Quando trabalhamos com Dockerfiles, é fundamental entender que o Docker utiliza um diretório como ponto de partida inicial para a construção da imagem. Isso significa que apenas os arquivos presentes nesse diretório e seus subdiretórios são acessíveis durante o processo de build.

Por exemplo, considere a seguinte estrutura de diretórios:

├ exemplo dockerfile
│   ├── docker
│   │   ├── Dockerfile
│   │   └── .dockerignore
│   └── package.json
│   └── server.js

Dockerfile:

FROM node:18

# Create app directory

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 8080

CMD [ "node", "server.js" ]

Se tentarmos executar o comando de build a partir do diretório docker, como o exemplo a seguir:

docker build -t image/teste .

Nos deparamos com o seguinte erro:

Esse erro ocorre devido a incapacidade do Docker de localizar os arquivos desejados, uma vez que o contexto atual, ou seja, o diretório docker, não inclui o diretório pai que contém os arquivos relevantes.

Então, qual é a solução?

Para garantir que a compilação seja bem-sucedida, é crucial ampliar o contexto de construção. Em vez de executar o comando de build a partir do diretório docker, você deve retornar à raiz do projeto e, em seguida, utilizar o seguinte comando:

docker build -f docker/Dockerfile -t image/teste .

Vamos analisar cada componente desse comando:

docker build: Este é o comando que dá início ao processo de construção da imagem Docker.

-f docker/Dockerfile: Especifica o arquivo Dockerfile a ser usado para construir a imagem.

-t image/teste: Essa opção define um nome (ou uma "tag") para a imagem que será criada.

".": O ponto no final do comando indica o contexto de construção, ou seja, o diretório no qual o Docker procurará o Dockerfile e quaisquer outros arquivos necessários para a construção da imagem. O ponto representa o diretório atual.

Após a execução bem-sucedida dessa instrução, você pode esperar o seguinte resultado:

Com essa abordagem, você consegue especificar qual Dockerfile deseja utilizar e também indicar qual é o contexto. O ponto "." representa a raiz do projeto e instrui o Docker a considerar esse ponto como o contexto inicial para a construção da imagem.