DDD: subclasses & raiz entidades

votos
9

Vamos dizer que eu tenho a entidade típico Car

class Car : Entity
{
    public double MaxSpeed { get; set; }
    public Color Color { get; set; }
    /* ... */
}

Esta entidade, no meu modelo de domínio, seria a entidade raiz de um agregado .

Agora vamos dizer que me especializar carros. I criar uma Ferrari , e os proprietários de Ferraris felizes gostam de chamá-los por um apelido:

class Ferrari : Car
{
    public string Nickname { get; set; }
}

Vamos dizer que eu tenho uma outra entidade, a Empresa entidade. Seria a entidade raiz de outro agregado . Há muitas pessoas que trabalham em uma empresa, representados pela entidade Pessoa . Pessoas podem ter carros. Mas o presidente de uma empresa é geralmente muito rico e este tipo de pessoas, eles têm Ferraris:

class President : Person
{
    public Ferrari Ferrari { get; set; }
}

Nesta situação, eu tenho a entidade Presidente, que é dentro do agregado da empresa , que está segurando uma referência a uma Ferrari, uma especialização da entidade raiz de outro agregado.

Isso é correto, tendo em vista DDD? Pode / I deve considerar a especialização de si mesmos entidades raiz como entidades raiz do mesmo agregado? Quer dizer, no domínio eu descrevi, é a entidade Ferrari também a entidade raiz do agregado carro (desde Ferrari também é um carro)?


Agora vamos dizer que eu tenho que persistem este modelo para um banco de dados . Eu acho que a minha pergunta não depende do quadro OR / M I irá utilizar.

Como devo construir a tabela com carros ? Devo construir uma única Carros de mesa, com uma coluna CarType (valores possíveis: Carro, Ferrari), e uma alcunha anulável coluna?

Ou eu deveria construir uma tabela para carros e uma mesa para Ferraris, este último um com sua PK uma FK Carros?

Obrigado!

Publicado 26/08/2009 em 23:42
fonte usuário
Em outras línguas...                            


3 respostas

votos
4

Você não deve usar a herança para modelar o seu domínio, porque em breve você vai ter problemas, uma vez modelo começa a ficar complexo.

Presidente é simplesmente um papel da pessoa ea pessoa pode ter várias funções. Talvez presidente tem apenas um papel, mas isso é simplesmente acidental, escolhendo exemplo errado.

Ferrari não deve ser herdada de carro quer. Não é óbvio na Ferrari exemplo, porque eles só fazem um tipo de carros, mas considere empresa fazer muitos tipos como vans, sedans, hatchbacks, caminhões e assim por diante. Você provavelmente vai querer fazer aulas para cada tipo que vai herdar de classe de carro. E então o que ... você vai fazer cinco classes Toyota que irá herdar de cada tipo? Tal como...

Car -> Sedan -> ToyotaSedan
Car -> Truck -> ToyotaTruck
Car -> Hatchback -> ToyotaHatchback

Isso seria ridículo.

Disclaimer: Eu não sei nada sobre sobre carros. Contudo...

Não use herança para modelar o seu domínio. Sempre.

Experimentá-lo sem herança e que também irá tornou-se óbvio como persistir seu domínio.

Respondeu 29/08/2009 em 21:21
fonte usuário

votos
3

Geralmente quando você cruza raiz agregada limites que só permitem a referência a ser do ID do outro agregado raiz. Você, então, usar esse ID para procurar o outro agregado em seu repositório.

Assim, no seu caso, você iria querer Presidente de ter um ID de carro e se você já precisou fazer algo para o carro do presidente, você usaria o ID de carro para ir para o repositório para pegar o carro. Presidente não ter uma referência para o próprio carro.

Agora sobre aquele Ferrari. É uma espécie de difícil aplicação que na terminologia DDD padrão. Normalmente você iria colocar alguma validação sobre a atribuição de um carro para um presidente. Ou talvez haja uma CarBuyingService apenas para presidentes que garante que você obtê-lo direito. Normalmente em especializações DDD não são eles próprios agregados raiz.

Respondeu 29/08/2009 em 21:23
fonte usuário

votos
2

Eu acho que você começa a perder muito da flexibilidade do sistema através da criação de tipos concretos dessas entidades. O tipo de relacionamento que você está implicando é algo que eu geralmente mão com uma entidade "Type". Por exemplo, você tem um carro. A Ferrari é um tipo de carro. As duas entidades que são suportados pelos que são um carro e uma CarType.

A maneira que você está falando sobre a fazê-lo, você teria que adicionar novas entidades cada vez que um novo tipo é introduzido. Se tudo o que você está tentando capturar é o "apelido" do carro, eu acho que é apenas um outro pedaço de dados, e não outra entidade. A menos que você tenha dados diferentes (por exemplo, diferentes nomes de propriedades) e / ou diferenças de comportamento em entidades de viaturas para diferentes tipos, você não ganhar muito com esta abordagem. Eu preferiria ter métodos de repositório como FindCarByType () e lidar com um tipo de entidade, para reduzir o risco.

Eu sou de nenhuma maneira um perito de DDD, e eu estou lutando com alguns conceitos (ou mais como lutar com as múltiplas interpretações de alguns conceitos). Eu estou achando que não há uma aplicação 100% puro, e que há nuances para cada implementação que eu já vi.

Editar Follows

Vejo que descaracterizou parte do que você tinha escrito. Vejo esse apelido não é para todos os veículos, mas apenas para Ferrari: Car. Eu acho que a resposta é realmente "depende". Quanto especialização de domínio que você tem no resto do seu modelo? Tendo um apelido pode ser prevalente entre entidades Ferrari, mas é exclusivo? Não é apenas sobre os dados reais, mas os requisitos. Basicamente se trata de quanto especialização você está esperando nessas entidades.

Respondeu 29/08/2009 em 20:52
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more