Visão Geral do Domain-Driven Design (DDD)

Introdução ao Domain-Driven Design (DDD) Domain-Driven Design (DDD) é uma abordagem de projeto de software centrada no domínio. Não existe uma única forma "correta" de implementar DDD, pois não é um padrão rígido. Ao longo da minha carreira como Engenheiro de Software, vi diversas implementações, cada uma com vantagens e desvantagens. O que é DDD? DDD é uma metodologia para projetar software modelando um domínio a partir do conhecimento de especialistas, usando uma linguagem ubíqua e dividindo o sistema em contextos delimitados. Os principais objetivos do DDD são: Focar no domínio central e na lógica de negócio; Criar designs complexos baseados em modelos do domínio; Promover colaboração entre especialistas técnicos e de negócio para refinar modelos conceituais iterativamente. Domínio O domínio é a área de negócio ou contexto específico da aplicação. Modelar bem o domínio é crucial, pois ele é o coração do software. Um modelo mal definido pode fazer com que o sistema se comporte de forma imprevisível. Linguagem Ubíqua É uma linguagem comum entre desenvolvedores e especialistas de negócio. Termos como "Cliente" ou "Pedido" devem ser consistentes no código, documentação e discussões. Isso evita ambiguidades e garante que todos entendam o mesmo conceito. Contexto Delimitado Ao modelar um domínio, definimos limites claros entre responsabilidades. Por exemplo: Quem é responsável por manter a relação entre duas entidades? Onde regras de negócio específicas devem residir? Esses limites evitam conflitos e garantem que cada parte do sistema tenha responsabilidade bem definida. Agregado Um agregado é um grupo de objetos (entidades e objetos de valor) tratados como uma única unidade. Acesso a um agregado é feito por meio de sua raiz de agregação, que controla regras de negócio e ciclo de vida. Importante: Um agregado não equivale a uma tabela no banco de dados. Em domínios complexos, um agregado pode ser resultado de consultas elaboradas. Objeto de Valor São objetos sem identidade única, como Endereço ou Número de Telefone. Sua igualdade é definida por seus atributos, não por um ID. Entidade O oposto de um objeto de valor: possui identidade única (ID), como Cliente ou Pedido. Eventos de Domínio Eventos emitidos pelo domínio ou raiz de agregação quando ocorrem mudanças ou ações. Exemplo: DomainEventPublisher.Publish(new PedidoCriadoEvent(pedido.Id)); Em arquiteturas como Event Sourcing, esses eventos são armazenados ou publicados em filas. Repositórios Mecanismos para abstrair o acesso ao banco de dados, fornecendo métodos para buscar e persistir agregados. Exemplo: public interface IRepositorioCliente { Cliente ObterPorId(Guid id); void Salvar(Cliente cliente); } Serviços Encapsulam lógica de negócio complexa ou processos que não pertencem a uma entidade ou agregado. Devem ser stateless (sem estado). Exemplo: public class ServicoPagamento { public void ProcessarPagamento(Pedido pedido) { // Lógica de integração com gateway de pagamento } } Conclusão Apresentei os conceitos centrais do DDD. Para aprofundar, recomendo o livro "Domain-Driven Design: Atacando as Complexidades no Coração do Software" de Eric Evans. No próximo artigo, mostrarei exemplos práticos de código!

Mar 20, 2025 - 01:21

Visão Geral do Domain-Driven Design (DDD)

Introdução ao Domain-Driven Design (DDD)

Domain-Driven Design (DDD) é uma abordagem de projeto de software centrada no domínio. Não existe uma única forma "correta" de implementar DDD, pois não é um padrão rígido. Ao longo da minha carreira como Engenheiro de Software, vi diversas implementações, cada uma com vantagens e desvantagens.

O que é DDD?

DDD é uma metodologia para projetar software modelando um domínio a partir do conhecimento de especialistas, usando uma linguagem ubíqua e dividindo o sistema em contextos delimitados.

Os principais objetivos do DDD são:

Focar no domínio central e na lógica de negócio;
Criar designs complexos baseados em modelos do domínio;
Promover colaboração entre especialistas técnicos e de negócio para refinar modelos conceituais iterativamente.

Domínio

O domínio é a área de negócio ou contexto específico da aplicação. Modelar bem o domínio é crucial, pois ele é o coração do software. Um modelo mal definido pode fazer com que o sistema se comporte de forma imprevisível.

Linguagem Ubíqua

É uma linguagem comum entre desenvolvedores e especialistas de negócio. Termos como "Cliente" ou "Pedido" devem ser consistentes no código, documentação e discussões. Isso evita ambiguidades e garante que todos entendam o mesmo conceito.

Contexto Delimitado

Ao modelar um domínio, definimos limites claros entre responsabilidades. Por exemplo:

Quem é responsável por manter a relação entre duas entidades?
Onde regras de negócio específicas devem residir?

Esses limites evitam conflitos e garantem que cada parte do sistema tenha responsabilidade bem definida.

Agregado

Um agregado é um grupo de objetos (entidades e objetos de valor) tratados como uma única unidade. Acesso a um agregado é feito por meio de sua raiz de agregação, que controla regras de negócio e ciclo de vida.

Importante: Um agregado não equivale a uma tabela no banco de dados. Em domínios complexos, um agregado pode ser resultado de consultas elaboradas.

Objeto de Valor

São objetos sem identidade única, como Endereço ou Número de Telefone. Sua igualdade é definida por seus atributos, não por um ID.

Entidade

O oposto de um objeto de valor: possui identidade única (ID), como Cliente ou Pedido.

Eventos de Domínio

Eventos emitidos pelo domínio ou raiz de agregação quando ocorrem mudanças ou ações. Exemplo:

DomainEventPublisher.Publish(new PedidoCriadoEvent(pedido.Id));

Em arquiteturas como Event Sourcing, esses eventos são armazenados ou publicados em filas.

Repositórios

Mecanismos para abstrair o acesso ao banco de dados, fornecendo métodos para buscar e persistir agregados. Exemplo:

public interface IRepositorioCliente 
{  
    Cliente ObterPorId(Guid id);  
    void Salvar(Cliente cliente);  
}

Serviços

Encapsulam lógica de negócio complexa ou processos que não pertencem a uma entidade ou agregado. Devem ser stateless (sem estado).

Exemplo:

public class ServicoPagamento 
{  
    public void ProcessarPagamento(Pedido pedido) 
    {  
        // Lógica de integração com gateway de pagamento  
    }  
}

Conclusão

Apresentei os conceitos centrais do DDD. Para aprofundar, recomendo o livro "Domain-Driven Design: Atacando as Complexidades no Coração do Software" de Eric Evans. No próximo artigo, mostrarei exemplos práticos de código!