🧠 Mapa Mental - Domain-Driven Design

Domain-Driven
Design (DDD)

🎯 Domain (Domínio) ▼

✨ Core do Business

Lógica de negócio essencial, o coração da aplicação

💡 Exemplo: "Um pedido só pode ser cancelado se ainda não foi enviado" | "Um cliente VIP tem 15% de desconto em todas as compras" | "Transferências acima de R$ 10.000 precisam de aprovação"

🔒 Não depende de nada

Camada completamente independente de frameworks e infraestrutura

📋 Entities (Entidades)

Objetos com identidade única e ciclo de vida próprio

💡 Exemplo: Cliente (CPF único), Pedido (ID único), Conta Bancária (número único). Dois clientes com mesmo nome são pessoas diferentes!

💎 Value Objects

Objetos imutáveis definidos por seus atributos, sem identidade

💡 Exemplo: Endereço (Rua X, 123), Dinheiro (R$ 100,00), Email (joao@email.com), CPF. Duas notas de R$ 50 são intercambiáveis!

🎭 Aggregates

Conjunto de entidades tratadas como uma única unidade

💡 Exemplo: Pedido (root) + ItensCarrinho + Cupom. Carrinho de Compras (root) + Produtos. Sempre acesse via root!

📐 Regras de Negócio

Políticas e validações que governam o domínio

💡 Exemplo: "Estoque não pode ficar negativo" | "Desconto máximo de 30%" | "Senha deve ter 8+ caracteres" | "Menor de idade não pode comprar álcool"

🔌 Interface Repository

Contratos para persistência de aggregates

💡 Exemplo: interface IClienteRepository { Salvar(Cliente), ObterPorId(Guid), ObterClientesVIP() } - SEM implementação aqui!

⚙️ Domain Services

Operações que não pertencem a uma entidade específica

💡 Exemplo: TransferenciaService (envolve 2 contas), CalculadoraDeFreteService, ValidadorDeCPFService, ServicoDeAutenticacao

📢 Domain Events

Eventos que representam algo importante que aconteceu no domínio

💡 Exemplo: PedidoCriadoEvent, PagamentoAprovadoEvent, ClienteCadastradoEvent, EstoqueBaixoEvent → Dispara email, notificação, etc.

💼 Application (Aplicação) ▼

🎬 Use Cases

Casos de uso da aplicação, orquestrando o domínio

💡 Exemplo: CriarPedidoUseCase, RealizarPagamentoUseCase, CancelarAssinaturaUseCase, AprovarCreditoUseCase

🔄 Application Services

Coordena operações entre camadas

💡 Exemplo: PedidoAppService orquestra: valida entrada → chama domínio → persiste → envia email → dispara eventos

📦 DTOs (Data Transfer Objects)

Objetos para transferência de dados entre camadas

💡 Exemplo: CreatePedidoDTO { produtoId, quantidade, endereco }, LoginDTO { email, senha }, PedidoResponseDTO { id, status, total }

🔀 Mappers

Conversão entre DTOs e entidades de domínio

💡 Exemplo: PedidoMapper.ToDTO(pedido) converte Pedido (entity) → PedidoResponseDTO. ToEntity() faz o inverso

✅ Validadores

Validações de entrada da aplicação

💡 Exemplo: CreatePedidoValidator verifica: produtoId existe? quantidade > 0? endereço válido? antes de chamar o domínio

🎯 Command Handlers

Processa comandos e coordena ações no domínio

💡 Exemplo: CriarPedidoCommandHandler recebe CriarPedidoCommand e executa a lógica, retorna sucesso ou erro

📊 Query Handlers

Processa consultas de dados

💡 Exemplo: ListarPedidosClienteQueryHandler recebe query com filtros → busca no BD → retorna DTOs otimizados (sem carregar aggregates completos)

🏗️ Infrastructure (Infraestrutura) ▼

💾 Repositories (Implementação)

Implementação concreta de persistência de dados

💡 Exemplo: PedidoRepositorySQL, ClienteRepositoryMongoDB - implementam as interfaces do domínio usando tecnologias específicas

🗄️ Database / ORM

Conexão com banco de dados (Entity Framework, Hibernate, etc.)

💡 Exemplo: Entity Framework Core mapeando Pedido para tabela "Pedidos", incluindo relacionamentos com ItensCarrinho

🌐 External APIs

Integração com serviços externos

💡 Exemplo: API de Pagamento (Stripe, PagSeguro), API de CEP (ViaCEP), API de Cotação (dólar), API de SMS (Twilio)

📧 Email / SMS

Serviços de notificação

💡 Exemplo: SendGrid envia email de confirmação de pedido, Twilio envia SMS com código de verificação 2FA

📂 File Storage

Armazenamento de arquivos (S3, Azure Blob, etc.)

💡 Exemplo: Upload de fotos de produtos → AWS S3, download de notas fiscais em PDF, armazenamento de documentos do cliente

🔐 Authentication

Implementação de autenticação e autorização

💡 Exemplo: JWT token validation, OAuth2 integration, verificação de roles/permissions (Admin, User, Guest)

📨 Message Queue

Filas de mensagens (RabbitMQ, Kafka, etc.)

💡 Exemplo: Publica "PedidoCriado" na fila → Worker consome → Envia email ao cliente / Atualiza estoque / Notifica entrega

💾 Cache

Redis, Memcached, etc.

💡 Exemplo: Cachear lista de produtos mais vendidos por 5 min, dados do usuário logado, resultado de cálculos pesados

🖥️ Presentation (Apresentação) ▼

🌐 API Controllers / REST

Endpoints HTTP da API

💡 Exemplo: POST /api/pedidos, GET /api/clientes/{id}, PUT /api/produtos/{id}, DELETE /api/carrinho/item/{id}

🔌 GraphQL Resolvers

Resolvedores GraphQL se aplicável

💡 Exemplo: query { pedido(id: "123") { id, status, items { produto, quantidade } } } → PedidoResolver busca dados otimizados

⚡ gRPC Services

Serviços gRPC para comunicação eficiente

💡 Exemplo: PedidoService.proto com RPC CriarPedido(CreatePedidoRequest) returns (PedidoResponse) - comunicação binária rápida

🎨 Views / UI

Interface de usuário (se não for API pura)

🔍 Request Validation

Validação de requests HTTP

🛡️ Middlewares

Autenticação, logging, tratamento de erros

💡 Exemplo: AuthMiddleware verifica JWT → LoggingMiddleware registra request → ExceptionMiddleware captura erros → retorna JSON padronizado

📄 Documentação (Swagger)

Documentação automática da API

🎯 Padrões Estratégicos ▼

🗺️ Bounded Context

Fronteiras explícitas onde um modelo se aplica

💡 Exemplo: No contexto de "Vendas", Cliente tem email e histórico de compras. No contexto de "Entrega", Cliente tem apenas endereço!

🗣️ Ubiquitous Language

Linguagem compartilhada entre devs e especialistas do domínio

💡 Exemplo: No banco, usar "Conta Corrente" (não "Account"). No e-commerce, "Carrinho" (não "Cart"). Use o idioma do negócio no código!

🔗 Context Mapping

Mapeamento de relacionamentos entre bounded contexts

💡 Exemplo: Contexto "Vendas" (Upstream) fornece dados para "Entrega" (Downstream) via API. Usar ACL (Anti-Corruption Layer)

⭐ Core Domain

Parte mais importante que diferencia o negócio

💡 Exemplo: Para Uber = Algoritmo de matching motorista/passageiro. Para Netflix = Sistema de recomendação. Para Nubank = Análise de crédito

🔧 Supporting Subdomain

Suporta o core domain mas não é o foco principal

💡 Exemplo: Sistema de notificações, Gestão de cupons de desconto, Relatórios de vendas, Sistema de avaliações

📦 Generic Subdomain

Funcionalidades genéricas que podem ser terceirizadas

💡 Exemplo: Autenticação (Auth0, Firebase), Envio de emails (SendGrid), Pagamentos (Stripe), Storage de arquivos (AWS S3)

🧱 Building Blocks Táticos ▼

📋 Entity

Objeto com identidade única que persiste no tempo

💡 Exemplo: Usuario { id: UUID, nome: "João", email }, Produto { sku: "PROD-123" }, Pedido { numeroControle: "2024-001" }

💎 Value Object

Objeto imutável sem identidade conceitual

💡 Exemplo: Money { valor: 100, moeda: "BRL" }, Email { valor: "joao@email.com" }, Cor { hex: "#FF5733" } - sempre imutáveis!

🎭 Aggregate

Cluster de objetos tratados como unidade

💡 Exemplo: CarrinhoDeCompras { id, cliente, produtos[], cupom, total } - tudo é salvo/carregado junto, mantém consistência interna

👑 Aggregate Root

Entidade raiz que controla acesso ao aggregate

💡 Exemplo: Pedido é o root. Para adicionar item ao pedido: pedido.adicionarItem(), NUNCA item.adicionarAoPedido()!

🏭 Factory

Encapsula lógica complexa de criação de objetos

💡 Exemplo: PedidoFactory.criarPedidoParaClienteVIP() - aplica regras, descontos, validações complexas na criação

📦 Repository

Abstração para acesso a aggregates persistidos

💡 Exemplo: IPedidoRepository { Salvar(), BuscarPorId(), BuscarPedidosAtivos() } - interface no domínio, implementação na infra

⚙️ Domain Service

Operações de domínio sem estado próprio

💡 Exemplo: CalculadoraDeDescontoService.calcular(cliente, produtos) - lógica que envolve múltiplos aggregates

📢 Domain Event

Representa algo importante que aconteceu

💡 Exemplo: ContaCriadaEvent { contaId, clienteId, data } - outros bounded contexts podem reagir a este evento

📊 Specification

Regras de negócio reutilizáveis e combináveis

💡 Exemplo: ClienteVIPSpec, ProdutoEmPromoçãoSpec, PedidoAprovadoSpec - pode combinar com AND, OR, NOT!

📚 Princípios Fundamentais do DDD:

1. Foco no Domínio: O domínio é o coração da aplicação. Todo o design gira em torno da lógica de negócio.

2. Colaboração: Desenvolvedores e especialistas do domínio trabalham juntos usando a Ubiquitous Language.

3. Isolamento: O domínio não depende de nada - nem frameworks, nem bancos de dados, nem UI.

4. Bounded Contexts: Cada contexto tem seu próprio modelo e linguagem. Evita o "Big Ball of Mud".

5. Arquitetura em Camadas: Separação clara entre Domain, Application, Infrastructure e Presentation.

6. Agregados: Garantem consistência através de transações em unidades lógicas de negócio.

🔄 Exemplo Completo de Fluxo - Criar um Pedido:

1. Presentation (Controller): Recebe POST /api/pedidos com { produtoId, quantidade, endereço }

2. Application (Use Case): CriarPedidoUseCase valida dados, converte DTO para comando

3. Domain (Aggregate): Pedido.criar() aplica regras: verifica estoque, calcula desconto VIP, valida quantidade

4. Domain (Domain Event): Pedido dispara PedidoCriadoEvent

5. Infrastructure (Repository): PedidoRepository.Salvar() persiste no PostgreSQL via EF Core

6. Infrastructure (Message Queue): Publica PedidoCriadoEvent no RabbitMQ

7. Infrastructure (Email): Worker consome evento e envia email de confirmação via SendGrid

8. Presentation: Retorna 201 Created com PedidoResponseDTO { id, status, total } ao cliente

🎯 Observe como: O domínio (passo 3-4) não sabe nada sobre HTTP, banco de dados ou email. Ele só conhece regras de negócio! As camadas externas (Application, Infrastructure, Presentation) orquestram e fornecem os serviços técnicos necessários.