Eu que agradeço pela thread. Levanta pontos bem interessantes.
Então, concordo que todos os atributos possuem relação com a classe, mas isso não muda o fato de que ela pode estar mal abstraída. Eu preciso partir de algumas premissas pra poder pensar em algumas soluções... Só um expert de negócios poderia confirmar essas minhas premissas, mas vamos a alguns "chutes". hehehe
Data de criação e atualização são informações de persistência, não de domínio, logo não entram na entidade. São "atributos virutais", como alguns ORMs chamam.
Loja muito provavelmente seria o Aggregate Root que tornaria o acesso a Pedido possível, logo seria redundante ter esse atributo em Pedido.
Pontos cartão de presente
Pontos fidelidade
Disclaimers aceitos
Papel de presente ou embrulho
Retirada na loja
Arquivos anexados
Todos esses acima, se entendi corretamente o conceito do domínio, se enquadram em DetalhesPedido ou algo do tipo, mas pode ser mais discutido, claro. Posso ter entendido errado.
Subtotal e total são valores calculados baseando-se nos produtos. Uma estrutura de Composite poderia ser aplicada até para ter "pedidos aninhados".
Pedido pode significar muita coisa dependendo do domínio. Às vezes pode ter uma Compra que possui vários pedidos. Às vezes um cliente pode realizar apenas um pedido por data. Se esses forem os casos, o Aggregate Root muda, retirando alguns outros atributos da classe.
Aí teriamos que entrar numa discussão bem mais aprofundada sobre o caso.
Mas ainda assim, se existe uma classe com antos atributos, chances são grandes de nem todos serem obrigatórios. Aí, a criação fica completa, o que normalmente pede uma espécie de Creation Method (que o DDD chama de Factory), Builder ou algo do tipo.
Eu que agradeço pela thread. Levanta pontos bem interessantes.
Então, concordo que todos os atributos possuem relação com a classe, mas isso não muda o fato de que ela pode estar mal abstraída. Eu preciso partir de algumas premissas pra poder pensar em algumas soluções... Só um expert de negócios poderia confirmar essas minhas premissas, mas vamos a alguns "chutes". hehehe
Data de criação e atualização são informações de persistência, não de domínio, logo não entram na entidade. São "atributos virutais", como alguns ORMs chamam.
Loja
muito provavelmente seria o Aggregate Root que tornaria o acesso aPedido
possível, logo seria redundante ter esse atributo emPedido
.Todos esses acima, se entendi corretamente o conceito do domínio, se enquadram em
DetalhesPedido
ou algo do tipo, mas pode ser mais discutido, claro. Posso ter entendido errado.Subtotal
etotal
são valores calculados baseando-se nos produtos. Uma estrutura deComposite
poderia ser aplicada até para ter "pedidos aninhados".Pedido
pode significar muita coisa dependendo do domínio. Às vezes pode ter umaCompra
que possui vários pedidos. Às vezes um cliente pode realizar apenas um pedido por data. Se esses forem os casos, oAggregate Root
muda, retirando alguns outros atributos da classe.Aí teriamos que entrar numa discussão bem mais aprofundada sobre o caso.
Mas ainda assim, se existe uma classe com antos atributos, chances são grandes de nem todos serem obrigatórios. Aí, a criação fica completa, o que normalmente pede uma espécie de
Creation Method
(que o DDD chama de Factory),Builder
ou algo do tipo.:-D
Insights massa, top!!! 👍👍👍👍👍👍👍
Obrigado pela discussão. Realmente me fez refletir aqui sobre algumas decisões que tomamos corriqueiramente.