Domain Driven projeto, SOC, e identificação da entidade

Question

Eu tenho tentado envolver minha mente em torno de DDD e como ela pode se relacionar com MVC, mas eu estou tendo problemas com relação à identificação da entidade.

Em particular, eu estou tentando manter a separação estrita entre meus modelos apresentação, domínio, e de dados. Meu desligamento aqui é em como eu preservar identificação da entidade através destas fronteiras. Para esclarecer, eu estou usando classes separadas para representar a mesma entidade em diferentes contextos - por exemplo, eu tenho uma classe de domínio 'ShipmentRequest', várias classes de apresentação 'ShipmentRequestView' (dependendo das propriedades requeridas por uma visão particular), e um 'shipment_request' tabela de banco de dados (o meu modelo de dados).

Eu me sinto como o uso de uma propriedade 'ID' (como ShipmentRequestId) seria uma violação da separação eu estou tentando alcançar, uma vez que esta propriedade ID é uma preocupação de banco de dados, e não uma preocupação de domínio; e eu não quero passar o mesmo objeto entre as camadas, pois isso significaria passar dados desnecessários em minha camada de apresentação.

Como preservar essa separação, e ainda acompanhar identidade entre essas camadas?

Answer 1

Sem o campo id na sua entidade não pode mapeá-lo para uma linha de banco de dados. Portanto, este campo id mesmo que ele não tem nada a ver com as suas entidades deve vazar para seu modelo de domínio.

Eu sinto que é mais frequentemente um exagero usar um modelo de apresentação, especialmente se o que você está tentando alcançar é esconder algumas propriedades.

Eu acho que a separação de interesses é impulsionada principalmente pelo contexto limitada. Por exemplo, a tabela Pessoa, PersonView e Pessoa todos parecem o relacionam com um contexto de processamento de transações. Em tal contexto, gostaria de fazer nem mesmo ter um PersonView ea tabela de pessoa seria abstraída.

Por outro lado, se você estiver em um contexto de relatórios, uma PersonView seria mais útil.

Eu acho que o contexto é muito mais importante do que qualquer esquema de camadas.

Quanto à falta de uma chave natural em sua entidade pessoa, isso poderia significar que essa pessoa não é realmente uma entidade. Por exemple, em qualquer aplicação na vida real, há sempre um número associado com a pessoa: um empregado tem um número de funcionário, um cliente como um número de conta, etc. Este id negócio é definitivamente parte do domínio

.

Answer 2

Eu acho que ter um campo "ID" em entidades é uma concessão muito (a maioria?) As pessoas acabam fazendo, e eu não me sentiria culpado por fazê-lo.

Como você diz, mesmo quando você não está lidando com o banco de dados, você ainda precisa de alguma noção de identidade. Você pode tentar chegar a algum tipo de identidade "natural" para cada entidade (um campo como nome, ou uma combinação de vários campos), mas isso nem sempre é possível. Mesmo quando é, ter um campo de identificação muitas vezes age como um shortform útil para dizer "a entidade cujo nome é X, e cuja data de nascimento é Y, e cuja SSN é Z".

No final, enquanto indiscutivelmente menos "puro", tendo um campo de ID vai coisas provável simplificar um grande negócio.

Answer 3

Expedição Request é definitivamente um exemplo melhor!

Como os usuários a encontrar uma solicitação de remessa? Dependendo da resposta que você pode precisar de um id que os usuários podem se lembrar, por exemplo 20091012-A.

Pode um ID de pedido embarque nunca mudar? Se não, use a tecla db de identidade.

Você vai precisar para transferir pedidos de remessa de um sistema para outro? Se sim, não use a chave db de identidade.

chave que quer que você usa você precisará torná-lo disponível no modelo de apresentação para que você pode criar links para ações sobre um pedido de embarque particular.