DDD não é uma receita para desenvolver software em camadas, mas sim uma abordagem de modelagem de software e praticas com o objetivo de implementas regras complexas. Processos de negócios que tratamos como domínio.
Sem um expert de negocio não é possivél fazer DDD, pode ser por exemplo um Product Owner.
Primeiro Passo: Mapear os contextos de negócio
Segundo Passo: Modelagem de Dominio
Se todos os contextos exergam uma classe produto, por exemplo, não é por isso que a mesma ira ficar inchada com as regras de todos eles. A mesma entidade pode ter papeis diferentes em cada dominio
- Aggregates
- Entities
- Value Types
- Factories
- Cross-aggregate behavior
- Repositories
- External Services
Pode ter validação
Faz tudo que a model não faz, ex.: conversar com repositórios e serviços externos. Apesar de ensinado por Eric Evans hoje em dia não é considerado boa pratica ter um serviço para cada model, ex.: produto service, clientes service etc. O serviço deve ser um cross aggregate behavior.
- Coleção de dados individuais
- Destinado a ser uma coleção de atributos
- Imutável
- Mais preciso que os tipos Primitivos
- Usa Ad hoc setters com lógica de validação
- Usa Ad hoc gettes
- Não possui Id, persistido como uma coluna na base dentro de uma entidade, Ex.: CPF
- Possuem identidade (ex.: possui id)
- Deve ser exclusiva para o objeto mapeado, Duas classes não podem significar a mesma coisa no mesmo contexto
- Possui estados e comportamentos
- Possui Logica de negócios, mas não faz persistência
- Tudo que não for adequado a outras camadas deve ficar na entidade.
- Um conjunto de entidades tratadas como uma unica entidade quando algum dado é alterado
- Entidade usadas e referenciadas juntas
- Possui raiz de agregação (Root Aggregation)
- Mantém a integridade do objeto
- Toda entidade raiz é também um agregado, mesmo que sozinha
- Os objetos filhos não devem serem manipulados individualmentes, somente através do root
- Valida a consistencia dos objetos filhos
- Segue a regra de negócio, quando uma entidade existe apenas outra ela deve estar agregada a ela, caso contrario é um root. Se duas entidades parecem duas raizes provavelmente são.
- Apenas um repositório por agregação (root).
- Representam uma itenção unica de negócio, ex.: Um camando para editar, um comando para inserir uma entidade. (A iserção e a edição podem ter regras de validação diferentes)
- Recebe um input,
- Manipula um comando para montar uma entidade
- Persiste a entidade no banco de dados
- Quando se usa esta camada, evita-se ter de criar um service pra persistir uma entidade. Ao crontaria do DDD classico onde o service faz o crud envelopando o repository, neste caso ele deve ser usado para processos com fluxos mais longos que envolvem mais de uma entidade