principlers DDD e concepção do projeto ASP.NET MVC

votos
5

Duas perguntas parte

I têm um agregado de produto que tem;

Preços PackagingOptions ProductDescriptions imagens do produto etc

Eu ter modelado um repositório de produto e não criar repositórios individuais para qualquer uma das classes filho. Todas as operações de db são processados ​​através do repositório do produto.

Estou compreensão do conceito DDD corretamente até agora? Às vezes, a pergunta vem à minha mente que ter um repositório para digamos opções de embalagem poderia fazer a minha vida mais fácil buscar diretamente uma opção de embalagem a partir do DB usando seu ID em vez de pedir o repositório produto para encontrá-lo em sua coleção PackagingOptions e dar isso para mim..

Segunda parte está a gerir a editar criar operações utilizando trabalho ASP.MVC quadro

Atualmente, estou tentando gerenciar todos os add editar remover destas coleções filho de produto através do controlador do produto (som certo?).

Um desafio que estou enfrentando agora é;

Se eu editar uma opção de embalagem específica do produto através

meudomínio / produto / editpackagingoption / 10

Eu tenho acesso ao ID da opção de embalagem

Mas eu não tenho o ID do que produto de auto e isso me obriga a escrever uma consulta a primeira a encontrar o produto que tem essa opção de embalagem específica, em seguida, editar que a opção de embalagem revelant produto e. Eu posso fazer isso, como todos opção de embalagem têm a sua identificação única, mas isso seria um fracasso se eu tenho coleções que não têm um ID único.

Que se sente muito errado ..

A próxima opção Pensei está enviando ambos os IDs de opções de produtos e embalagens na url como;

meudomínio / produto / editpackagingoption / 3/10

Mas eu não tenho certeza se isso é um bom design também.

Então, eu estou em um ponto que eu estou um pouco confuso. pode estar tendo desentendimentos fundamentais em torno de tudo isto ...

Eu apreciaria se você carregar com a pergunta longa e me ajudar a colocar isso em conjunto. obrigado!

Publicado 27/08/2009 em 00:32
fonte usuário
Em outras línguas...                            


2 respostas

votos
3

Em minha opinião, esta é uma daquelas coisas enlameadas que aparece em DDD.

No código, eu trato uma raiz agregada como um recipiente para todos os "relacionamentos" que tem e quaisquer objetos de entidade que não pode existir sem a raiz Aggregate.

Por exemplo, vamos pegar o cliente-> ordem-> LineItem-> exemplo de produto que foi espancado até a morte por agora. A raiz agregada como eu já exibido é cliente neste cenário. Dito isto, você não quer sempre chegar ao fim através do cliente. Você pode querer encontrar ordens em uma data específica.

Transformando-o em que é lado, você também não teria um cliente que não tem uma ordem. Os dois estão em uma relação simbiótica um pouco de modo que não é a raiz agregado do outro.

O ponto é que você não quer ter que carregar um cliente através de uma ordem, mas você não necessariamente deseja carregar um pedido através o cliente quer.

A partir de Ordem, no entanto, é improvável que você iria querer apenas recuperar um LineItem e você certamente não vai ser criá-los w / o uma ordem. Para esse fim, a Ordem serve como porta de entrada para LineItems. LineItems não precisam de seu próprio controlador ou repositório. Eles só existem dentro da própria Ordem e, como tal, fazem parte da Ordem (neste caso, Ordem se torna a raiz agregada) e são geridos pela Entidade Order.

Mas, um LineItem provavelmente teria uma relação a um produto dentro do sistema. Produtos que têm os seus próprios controladores, repositórios, etc, porque eles podem existir fora da raiz Aggregate.

Em resumo para minhas divagações, que tendem a olhar para ele desta forma: se uma entidade pode existir por si só, ele deve ter um controlador. Entidades que não podem existir por conta própria (LineItems neste caso) só deve ser administrada exclusivamente pelo seu recipiente (raiz agregada).

Será que alguns puristas DDD por favor me corrija se / onde eu estou errado?

Quanto à segunda parte da sua pergunta, eu precisaria de mais alguns detalhes sobre como você imaginar essas outras entidades que trabalham. Com o que você colocou aqui, eu imagino que PackagingOptions estão relacionadas a um produto e seria parte de uma raiz agregada de Produto. Agora, o que implica que você está editando-los levanta a questão de se a isto uma tabela de pesquisa no sistema ou são únicos valores e, como tal, devem ser tratados como objetos de valor?

Respondeu 27/08/2009 em 01:33
fonte usuário

votos
1

Kaivalya,

Quanto à sua última comentário (http apátrida):

Depende do contexto. Antes de entrar em detalhes, devo dizer-lhe um princípio básico sobre agregados:

Agregados definir um grupo de objectos relacionados que devem ser tratados como uma unidade única para efeitos de alteração de dados.

Isso é extremamente importante. A finalidade de ter Agregados é impor invariantes. Por exemplo, você pode ter uma política como "um pedido não pode exceder R $ 500". Então, para fazer cumprir esta política, você coloca Ordem e OrderItem juntos na ordem Aggregate. Desta forma, sempre que você adicionar um novo OrderItem, deve ser adicionado via objeto Order. Lá, você pode verificar o preço total e se certificar de que não exceda $ 500. Se você não tem essas invariantes em seu domínio, então não há nenhum ponto de carregar todos esses objetos juntos.

Agora, voltando ao seu comentário:

Se você tem invariantes que devem ser aplicadas, então é bom para carregar todo o agregado, embora possa ter alguma sobrecarga. Sim, HTTP é apátrida e você carregar todo o seu agregado apenas para modificar um dos seus objetos filho e, em seguida, jogá-lo fora. Está tudo bem. O que é importante a mais aqui é que está a fazer cumprir seus invariantes. Isto é o que DDD é para.

O objetivo do DDD é capturar todas as lógicas de negócios em seu domínio. Você poderia definitivamente alcançar um desempenho melhor se você não tem que carregar todo o agregado, mas como você fazer valer os seus invariantes? Você seria mais provável tem que fazê-lo em seu procedimento armazenado. Sim, ele funciona, e é rápido, mas lidar com lógica de negócio em procedimentos armazenados durante a manutenção é um pesadelo. É por isso que DDD evoluiu. Então você pode modelar seus requisitos de negócios usando orientada a objeto linguagens / ferramentas, então eles são mais fáceis de compreender e modificar.

Basta lembrar, DDD é uma grande abordagem, mas não para todos os tipos de projetos. Se você está lidando com um projeto no qual há muitas lógicas de negócio e as chances de eles mudam devido à natureza de um negócio é alta, então você deve usar DDD. No entanto, se o seu projeto é mais um "ler algo / escrever algo" sem muita lógica de negócios envolvidos, utilizando DDD é uma dor de cabeça. Você poderia simplesmente usar o LINQ to SQL (ou SqlDataAdapters) e enviar seus objetos para seus pontos de vista. Você não precisa nem se preocupar com Entidades encontrar, objetos de valor, agregados, Repositórios, etc.

Espero que isto ajude,

Mosh

Respondeu 06/04/2010 em 08:58
fonte usuário

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