- O padrão de modelo de domínio foi apresentado inicialmente por Martin Fowler no livro PoEAA.
- O Eric Evans apresenta um conjunto de padrões com objetivo de relacionar código com o modelo do domínio de negócio.
- Trata-se de um conjunto de ferramentas para implementar o padrão de modelo de domínio.
- O padrão é o modelo de domínio e os blocos de construção são os agregados, objetos de valor e serviços de domínio.
- O padrão modelo de domínio é para lidar com lógicas de negócio complexas, isto é, transições de estado complexas, regras de negócio e invariantes.
- As invariantes são regras que devem ser cumpridas o tempo todo.
- Usar o padrão registro ativo pode levar à duplicidade e implementações errôneas das regras de negócio.
- O uso dos padrões permite:
- colocar a lógica de negócio em primeiro lugar
- os objetos não devem introduzir complexidade acidental extra (a lógica de negócio é complexa)
- os objetos não devem ter lógica de infraestrutura
- os objetos devem ser puros
- o código fala a linguagem ubíqua e segue os modelos mentais dos especialistas de domínio
- Os blocos de construção são:
- objeto de valor
- é identificado pela composição de seus valores
- não tem identificador
- comunica a intenção
- não precisa validar os valores antes da atribuição
- a lógica de negócio reside no próprio objeto
- a lógica é implementada em um único lugar e é fácil de testar
- expressa o conceito do negócio e fala a linguagem ubíqua
- diminui a necessidade de convenções
- torna o uso do modelo de objeto menos propenso a erros e mais intuitivo
- deve ser implementado como objeto imutável
- evita o mau cheiro conhecido como obsessão por primitivos
- a obsessão por primitivos é representar conceitos de domínio de negócio através de tipos primitivos
- evita lógica de validação duplicada
- é difícil aplicar a lógica de validação antes de usar os valores
- o tipo String é um objeto de valor
- as strings são imutáveis e todas as operações resultam em uma nova instância
- o tipo de string encapsula um comportamento rico que cria novas instâncias
- não possui efeitos colaterais e são seguros
- usado para descrever propriedades de outros objetos
- exemplos: telefone, email, status, dinheiro e valores monetários
- entidades
- tem identificador
- pessoas com mesmo nome são pessoas diferentes
- exemplo: João da Silva com CPFs diferentes
- pode-se usar um objeto de valor para o identificador
- o identificador pode ser um uuid, número, string ou valor de domínio
- o identificador deve ser exclusivo e imutável
- a entidade é mutável e espera-se que mude ao longo do tempo
- existe a partir de um agregado
- agregado
- é uma hierarquia de entidades
- o objetivo é proteger a consistência dos dados
- é uma fronteira de aplicação da consistência
- a lógica do agregado tem que validar todas as modificações recebidas e garantir consistência
- os métodos de um agregados são referidos como comando
- a interface pública é responsável por validar a entrada, aplicar todas as regras de negócio relevantes e invariantes
- a camada de aplicação que orquestra os agregados são simples
- a camada da aplicação aplicam o transaction script
- o agregado atua como um limite transacional
- todas as mudanças no estado do agregado devem ser enviadas como uma única operação atômica
- nenhuma operação do sistema pode assumir uma transação multiagregada
- uma mudança no estado de um agregado só pode ser enviada individualmente
- isto é, um agregado por transação do banco de dados
- o uso de um agregado por transação força projetar cuidadosamente os limites de um agregado
- a necessidade de múltiplos agregados sinaliza um limite transacional errado
- a entidade é um bloco de construção de um agregado
- o agregado agrega entidades de negócio e objetos de valor que pertencem ao mesmo limite transacional
- recomenda-se manter o agregado o menor possível
- pode referenciar outros agregados pelo identificador
- a raiz do agregado é a entidade designada como interface pública do agregado
- deve usar a linguagem ubíqua
- o código deve ser baseado na mesma linguagem que programadores e especialistas de domínio utilizam
- evento de domínio
- é uma mensagem que descreve um evento significado que ocorreu no domínio de negócio
- os nomes devem ser formulados no passado
- fornece os dados relacionado ao evento
- são parte da interface pública do agregado
- um agregado publica seus eventos de domínio
- outros processos, agregados ou sistemas externos podem responder ao evento de domínio
- serviços de domínio
- lógica de negócio que não pertence a um agregado ou objeto de valor
- lógica de negócio que é relevante para múltiplos agregados
- é um objeto sem estado que implementa a lógica de negócio
- facilitam a coordenação de múltiplos agregados
- não se deve usá-lo para burlar a regra de um agregado por transação
- usar para lógica que requer leitura de múltiplos agregados
- não tem nada a ver com microsserviços
- objeto de valor
- Os padrões agregados e objeto de valor reduz a complexidade ao encapsular as invariantes.
- O padrão modelo de domínio é aplicado apenas para subdomínios com lógica de negócio complexa, isto é, subdomínios principais.
Created
April 5, 2026 23:44
-
-
Save marcelgsantos/8cc780f700e6e4f83676e8f62e454300 to your computer and use it in GitHub Desktop.
Anotações do Livro Aprenda Domain-Driven Design do Vlad Khononov
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment