DDD - Duvidas sobre tipos eNums....

[Desenvolvimento Gmail]

Boa tarde pessoal.... Estamos aqui na empresa desenvolvendo uma aplicação Web ASP.NET MVC, usando os conceitos do DDD. Porém apareceu uma dúvida conceitual:

 

Na camada de Dominio uma entidade, exemplo: Cliente, possui em sua propriedade um tipo enumerado eSexo(Masculino/Feminino). Porem já na camada de apresentação, estamos trabalhando com DTO`s, com isso tenho um objeto ClienteDTO. A dúvida, é como deve tratar o tipo enumerado no DTO? Devo criar um tipo enumerado eSexoDTO, ou utilizo o tipo enum eSexo da camada de dominio?

 

Obrigado pela atenção.

 

Rennes....

[Fernando Mondo]

eu ficaria com a segunda opção, não vejo motivos para o contrário.

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Acaz Souza Pereira]

Passaria o resultado do enum em string mesmo pela ClienteDTO.

Em 2 de julho de 2012 16:16, Desenvolvimento Gmail <rennes...@gmail.com> escreveu:

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
[Acaz Souza Pereira]

MSN/GTalk: acaz...@gmail.com
Skype: acazsouza
Cel:  (31) 8706-4103

twitter.com/acazsouza

acazsouza.com.br

[Gerson Dias]

Em nossos projetos criamos um atributo que decoramos cada item do enum com a descrição que deve aparecer na tela, depois fizemos um método de extensão para o enum que retorna essa string. Então fica algo do tipo

public enum Sexo

{

     [Description("FEMININO")]

     Feminino = 0,

     [Description("MASCULINO")]

     Masculino = 0

}

e quando quero passar para a tela posso usar algo do tipo cliente.Sexo.GetDescription();

Acho bem elegante...

2012/7/2 Acaz Souza Pereira <acaz...@gmail.com>

[Desenvolvimento Gmail]

 

Mas, se eu usar a camada de dominio na camada de apresentação por causa do tipo enumerado, a camada de apresentação ficaria dependente da camada de dominio e da camada de aplicacao (DTO). Por outro lado, se eu usar somente DTO's na minha camada de apresentação esta camada só dependeria da camada de aplicação. Conceitualmente não sei qual é o certo.

[Daniel Moreira Yokoyama]

1) Pergunta: Por que você está usando DTO's?

Não leve a mal, mas talvez o problema seja este. É bem possível que você não precise usar DTO's (a menos que você esteja usando alguma distribuição entre a aplicação e o domínio, e isto também, na maioria das vezes, não é necessário).

2) Fato: Não há nenhum problema na camada de apresentação depender da camada de domínio, afinal, esta dependência existe conceitualmente (eu não posso criar uma aplicação de controle de estoque sem depender do controle de estoque). O contrário (a camada de domínio depender da camada de apresentação) é que seria um problemão.

Entenda, o problema de over-design-patternation-compliance é que às vezes esquecemos de pensar um pouco antes de aplicar o pattern. Remover dependências é o ato de remover de forma sensata as dependências que não são saudáveis existirem por questões de manutenção. No entanto, algumas dependências existem independente do que façamos. Por exemplo, sua camada de apresentação não "depende diretamente do domínio", mas depende do DTO que foi criado só pra fazer o wrapper do domínio. Isto não faz sentido, entende? Por que no fundo, ela depende sim do domínio, e o domínio não é algo plugável, é o seu business propriamente dito. A apresentação é que poderia (se é que é necessário) ser plugável.

3) Se ainda assim achar realmente necessário manter os DTO's por quaisquer motivos que vc achar necessário, quando a informação sai do controle do domínio, ela precisa representar o domínio da forma mais expressiva possível. Neste ponto, se é que você quer mesmo manter tudo isso deste jeito, eu concordo com a sugestão do Gerson, por que o objeto serializado não possuirá um dado qualquer a ser transformado, mas terá uma informação valorosa, por que é descritiva. Afinal "Masculino" e "Feminino" são muito mais expressivos que "0" ou "1" no ponto de vista de quem "consome" o domínio. Isto é, o valor da informação está contido no objeto sem precisar da ajuda de terceiros para descobrir seu significado.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Eduardo Pires]

Mandou bem!

Parabéns pela clareza!

Faço das suas as minhas...

Enviado pelo meu iPhone.

[Michel Barbosa]

Rene,

 

Na minha opnião ao invés de utilizar objetos DTO utilizaria Viewmodel, isto é criar um objeto que representa a view.

 

Também utilizaria o padrão facede para encapsular a regra de negocio e disponibilizar para a view somente o que for necessario. A Viewmodel deverá implementar uma interface, isto tem que ser feito para não exisitir acoplamento entre as camadas de dominio e apresentação.

 

Abraços.

[Juan Lopes]

Façade.

E usar o padrão façade para esconder a API do próprio domínio é assumir que não fez um bom design.

2012/7/3 Michel Barbosa <miche...@gmail.com>

--
https://github.com/juanplopes

[Daniel Moreira Yokoyama]

Façade, não. pelamor.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Desenvolvimento Gmail]

No meu caso aqui. devo utilizar o DTO, pois a camada de aplicação tambem vai ser utilizada em aplicacoes WCF, e o DTO satisfaria o MVC (ViewModel) e WCF (DTO).

 

----- Original Message -----

From: Michel Barbosa

To: dotnetar...@googlegroups.com

Sent: Tuesday, July 03, 2012 5:56 PM

Subject: Re: [dotnetarchitects] DDD - Duvidas sobre tipos eNums....

[Desenvolvimento Gmail]

 

Bom dia Daniel...

 

Obrigado pela resposta....

 

Aqui nós usamos o DTO pois, a intenção é de ter mesmo uma camada de apresentação plugavel (Mobile, Web e Desktop), podendo ser distribuida. Para aplicações que usam views o DTO assumiria a caracteristica de ViewModel, e nas aplicações distribuitas o DTO seria ele mesmo. Nesse cenário, ao seu modo de ver, por que não seria necessario a utilização do DTO? Existe uma melhor maneira para se fazer isso?

 

Uma outra questão, como tenho pouca experiencia em aplicaçoes distribuidas, ao se usar a camada de dominio na camada de apresentação, não ocorreria o problema de ser acessados metodos de objetos do modelo, no caso ocasionaria chamadas remotas?

 

Eu estava querendo usar o no ClienteDTO um ou tipo enumerado eSexoDTO(Masculino/Feminino), ao inves de string("Masculino"/"Feminino"), ou inteiro (0 ou 1). Por ter um valor tipado, ganharia na clareza. Na sua opinião, em tudo que foi lido, o que você mudaria?

 

Estamos adotando o coneceito de DDD aqui na empresa, porém é dificil achar alguem para debater e esclarecer alguns pontos. A sua opnião é de grande valia para nós. Buscando refinar os nosso conceito sobre DDD para atingir sempre um melhor produto.

 

Rennes...

 

----- Original Message -----

From: Daniel Moreira Yokoyama

To: dotnetar...@googlegroups.com

[Michel Barbosa]

Apenas para esclarecer.

 

Não sabia que teria WCF na jogada.

 

O WCF faz o papél da Facede, onde a regra de negócio fica toda encapsulada,e a view consume tudo que foi descriminado no contrato WCF.

 

E claro na minha opnião usar facace não que dizer que o design da arquitetura foi montado errado. O proprio eric evans fala sobre isto no livro de DDD.

 

Abraços

[Juan Lopes]

Façade.

2012/7/4 Michel Barbosa <miche...@gmail.com>

--
https://github.com/juanplopes

[Ricardson Albuquerque]

façade = Français

facade = English

facede = nao existe.

2012/7/4 Juan Lopes <m...@juanlopes.net>

--
Ricardson Albuquerque

[Hugo Estevam]

Rennes,

 

Na minha opinião a utilização do DTO não pode substituir a utilização do ViewModel (se você quer usar esse padrão). São coisas totalmente diferentes, mesmo tendo o DTO, você precisa do ViewModel para que a View possa fazer o databinding corretamente. Porém pelo que tenho lido existem dois tipos de ViewModel, os "originais" vindos do Silverlight e WPF e os "adaptados" ao MVC. Então minha afirmação acima pode não fazer sentido para a aplicação no seu sistema :-) pois falo do primeiro caso.

 

View -> ViewModel -> Model

no seu caso

View -> ViewModel -> DTO

 

Perceba que para criar um ViewModel você precisa das informações vindas da camada abaixo: Um exemplo seria na View do cliente ter um campo "Nº do certificado de reservista". Quem deve conter a regra para a exibição desse campo é o ViewModel, que faria uma analise no DTO (ou Model) recebido e se o sexo for masculino alteraria uma propriedade booleana "exibirNumReservista" para true. Com isso a View poderia fazer um databinding diretamente nessa propriedade do ViewModel.

 

Na minha visão o ViewModel deve ser usado neste sentido, porém varia muito de cenário para cenário, confesso que em alguns casos pode só gerar complexidade e mais trabalho.

 

Quanto ao uso do padrão Facade não vejo nada de errado, normalmente em sistemas no modelo que você citou com vários tipos de Clients, a API do dominio acaba tendo uma granularidade baixa e em alguns casos por questões de desempenho, justifica-se o uso desse padrão para aumentar o desempenho de chamadas remotas com alteração para granularidade alta.

 

um abraço,

Hugo Estevam

Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com

[Michel Barbosa]

Sem comentarios. Estou no grupo para aprender e contribuir de forma positiva.

> --
> Ricardson Albuquerque

[Antonio Pedro]

Faltou em português: Fachada.

Isso levanta uma coisa importante, por favor não levem para o lado pessoal, mas reflitam sobre isso.

Conheço muitos programadores que não escrevem bem em nossa língua pátria.

Será que os mesmos escrevem um bom código?

Todos nós programadores somos escritores, apenas escrevemos em outro "idioma".

Att,

Antônio Nascimento

---

Date: Wed, 4 Jul 2012 14:59:36 -0300

Subject: Re: [dotnetarchitects] DDD - Duvidas sobre tipos eNums....

From: miche...@gmail.com
To: dotnetar...@googlegroups.com

[Marcelo Vieira]

Algumas conclusões minhas sobre as opiniões já postadas:

- Pode-se usar o WCF fazendo o papel de FACADE tranquilamente;

- Boa ideia do Gerson Dias de anotar os ítens do ENUM com as descrições de cada item.

- Nota: apesar de o WCF ser usado como FACADE sugiro que as ANOTAÇÕES WCF(DataContract e DataMember, ServiceContract e OperationContract) sejam colocados diretamente sobre os tipos (DTOs/MODEL) e sobre as interfaces de contratos de serviço de aplicação também diretamente.

- O tão discutido de que não é nenhum problema da camada de apresentação depender da camada de domínio, realmente não há problema. Mas não é regra. Mas também não podemos confundir: -- A ENTIDADE de domínio é preparada para "manter" e "disponibilizar" (no/do repositório) as características e comportamentos de negócio, atendendo a regras deste. Mas a entidade de domínio geralmente não atenderá sozinha aos requisitos da forma de apresentação da informação, que poderá, essa apresentação, variar seu formato conforme a tela, o módulo do sistema, o dispositivo/recurso de saída (dispositivo móvel, browser, desktop,...). Entra então em cena os DTO como/e/ou/MODEL (do MVVM).

Minha sugestão é:

- Criar um projeto-assembly de CONTRATO donde ficariam todos os objetos de valores (ENUMs, STRUCTs, ...) do DOMÍNIO, portanto o projeto de domínio e o projeto Client irá conhecer esse projeto de contrato;

- Ainda nesse projeto estariam também os contratos (as interfaces) dos serviços da camada de aplicação (DDD) e seus TIPOS (DTO-MODEL) que seriam trafegados entre a camada dos usuários (UserInterface, Presentation, ...);

\Sob as camadas DDD:

                \APRESENTAÇÃO

                                +ProjetoDoCadastroDeCliente

                                               - CadastroDeClienteView

                                               - CadastroDeClienteViewModel

                                               - [Depende da IDadosDoClienteModel]

                \APLICAÇÃO

                               +ProjetoDoContrato

                                               - ICadastroDeClienteApp.cs

                                               - Sexo.cs (enum)

- IDadosDoClienteModel.cs

                                               - DadosDoClienteDTO ou DadosDoClienteModel

                               +ProjetoDeServicoDoCadastroDeCliente

                \DOMÍNIO

                               \Entidades

                                               - Cliente.cs

                \INFRA

                               \Repositório

                               \etc...

[Juan Lopes]

Você fala "A ENTIDADE de domínio é preparada para "manter" e "disponibilizar" (no/do repositório) as características e comportamentos de negócio, atendendo a regras deste".

E cita DDD.

Isso é incoerente.

2012/7/5 Marcelo Vieira <marcel...@gmail.com>

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--
https://github.com/juanplopes

[Daniel Moreira Yokoyama]

Marcelo, não Sei de onde você tirou essas ideias (e pra ser sincero não estou interessado em saber) mas você ainda precisa saber do que se trata o ddd.

--

[Daniel Moreira Yokoyama]

Também não entendi a questão de usar wcf com a justificativa de que vai distribuir para devices. Ora, distribua então para devices e deixe o site livre do wcf. Ou procure alternativas, como uma api rest usando nancy ou openrasta.

[Desenvolvimento Gmail]

 

Marcelo.... Estou gostando dessas trocas de idéias...

 

Esse seu modelo apresentado esta muito parecido com o meu... A diferenção é nos tipos enumados.... considero que Sexo.cs (enum) ele fique na camada de dominio, pois ele pertence ao dominio.... e ja o SexoDTO.cs fique na camada de aplicacao, juntamente com outros DTO's. Desse jeito, a minha camada de apresentação nao precisaria de conhecer a camada de dominio (não teria importancia tambem se conhecer). E tambem a vantagem de se trabalhar com o tipo enum em vez de string na camada de apresentação é que com tipos enumerados é mais simples e facil de se trabalhar do que strings pois se trata de valores tipados.

 

Como os tipos DTO's nao possuem os métodos que as entidades da camada de dominio tem, seria mais simples trabalhar com os tipos DTO's na camada de apresentação. O que vc acha dessa ideia?

 

\Sob as camadas DDD:

                \APRESENTAÇÃO

                                +ProjetoDoCadastroDeCliente

                                               - CadastroDeClienteView

                                               - CadastroDeClienteViewModel

                                               - [Depende da IDadosDoClienteModel]

                \APLICAÇÃO

                               +ProjetoDoContrato

                                               - ICadastroDeClienteApp.cs

                                               - IDadosDoClienteModel.cs

                                               - DadosDoClienteDTO ou DadosDoClienteModel

                                               - DatosDoClienteListDTO ou DadosDoClienteListModel

                                                - SexoDTO.cs (enum)

                               +ProjetoDeServicoDoCadastroDeCliente

                \DOMÍNIO

                               \Entidades

                                               - Cliente.cs

                                              - Sexo.cs (enum)

                \INFRA

                               \Repositório

                               \etc...

 

Rennes...

 

 

--

[Daniel Moreira Yokoyama]

Dear god, man.

[Eduardo Pires]

Daniel,

Não entendi a expressão, me pareceu como uma reprovação.

Nesse caso seria interessante se assim como o Rennes, montasse um modelo estrutural para entendermos seu ponto de vista.

Estamos todos aprendendo uns com os outros...

2012/7/5 Daniel Moreira Yokoyama <moreira....@gmail.com>

Dear god, man.

[Daniel Moreira Yokoyama]

Eduardo,

Eu dei a minha opinião a respeito de DTO's, Façade e WCF, bem como que tipo de abordagem eu faria alguns e-mails atrás.

ViewModels pra mim são úteis sim... mas são coisas completamente diferentes de DTO's.

A primeira coisa que eu faria era não criar a distribuição a menos que achasse extremamente necessário (distribuir para devices não justifica distribuir para a aplicação web, que pode não só consumir o domínio diretamente, como ainda pode, se possível, servir de host para a api que os devices usarão).

Mesmo que a distribuição acabe acontecendo, eu sempre evito ao máximo usar WCF (e o design que acabaria sendo necessário implementar para usá-lo). Eu usei OpenRasta nos meus últimos projetos, e ele até atendeu bem, mas tem uma configuração um pouco chata. Alguns preferem usar o próprio asp.net mvc para implementar uma api. Eu até acho que isso ajuda, se você conseguir lidar com as restrições do modelo. Mas também existe o Nancy, que é bem bacana e bem menos chato que o OpenRasta, que inclusive serviu de base pra Microsoft criar o Web API que faz parte do novo asp.net (ainda em release candidate... mas talvez valha a pena esperar).

Volto a dizer que o fato de distribuir para devices não significa necessariamente que o site precise consumir o serviço também. Mas hoje em dia, com a abordagem de SPA (Single Page application) e frameworks como o backbone, fica fácil justificar a api como provedora para o site (que vai virar estático). Mas nem sempre é necessário (e bom) ir por este caminho, apesar das vantagens (deixar o site em uma cdn e aproveitar todas as vantagens do http para escalar o serviço) existem desvantagens (como ter que lidar com SEO).

Enfim... tem um mundo inteiro fora do WCF... e um inferno dentro dele.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Eduardo Pires]

Daniel,

Agora sim, ficou bem melhor o nível do debate.

Talvez nem todos aqui devem atuar como arquitetos, mas uma coisa que eu acostumei é: Sempre terá alguém que irá criticar sua arquitetura e defender uma "melhor".

Com base nisso eu não vejo nada como certo e errado, e sim como atende e não atende.

Você abordando sua defesa de forma clara como acabou de fazer, enriquece o debate e mostra outros mundos (que as vezes nem todos conhecem).

Abç!

[Daniel Moreira Yokoyama]

Cara, eu sei que eu sou meio chato... mas é que, apesar de eu concordar com você que não existe o "certo", (como eu mesmo sugeri várias alternativas) eu discordo quando você diz que não existe o "errado". Existe sim... muitos errados.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Denis Ferrari]

Oi Pessoal,

Os pontos que eu abordaria o Daniel já explicou muito bem.

Vejo muitos extremismos na busca da "arquitetura perfeita". Coisas do tipo: "se eu não aplicar todos os padrões que eu sei então não está bom", o que resulta em soluções rebuscadas para coisas simples.

Enfim, só um pensamento solto.

Denis Ferrari
Desenvolvedor
"Faça pouco, faça sempre e faça direito."

Blog: www.heroisdati.com
Msn: denisf...@live.com
Skype: denis.n.ferrari
Twitter: @denisferrari
Facebook: facebook.com/denisnferrari
Linkedin: denisferrari

[Lemol Morais Lutonda]

+1
Infelizmente existem muitos errados!

El 05-Jul-12 9:59 PM, Daniel Moreira Yokoyama escribió:

Participe en la XVI Convención Científica de Ingeniería y Arquitectura del 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu
Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu

[Marcelo Vieira]

Juan Lopes e @dmyoko,
só para me fazer mais claro, quando eu disse:

"A ENTIDADE de domínio é preparada para "manter" e "disponibilizar" (no/do repositório) as características e comportamentos de negócio, atendendo a regras deste"

realmente quiz citar no sentido conceitual e figurado, ou seja, o domínio NÃO persiste a informação, as entidades de domínio são "colocadas" e "extraidas" apartir do repositório que cuida da persistência.

Rennes,
Os tipos enumerados, que no contexto que você apresentou são os objetos de valor do DDD, ficam no domínio sim, mas conforme já foi citado nas discuções, a VIEW pode, mesmo que não obrigatoriamente, ser conhecer o domínio. Mas há quem não gosta de expor, como eu, o domínio para os Clients, principalmente numa aplicação distribuida. Mas no meu caso eu não exponho as entidades de domínio, porém os objetos de valor eu exponho sim, por isso eu sugeri que você colocasse os objetos de valor num projeto separado e esse projeto, especificamente, viajaria sim para os Clients.

Marcelo Vieira

[Daniel Moreira Yokoyama]

Cara, insisto que ainda há muito equívoco no seu entendimento sobre ddd.

a única diferença entre entidade e objecto de valor é que a primeira pode ter seu estado alterado mas continua sendo a mesma (não se identifica pelo estado e sim por uma identidade) e o segundo é definido pelo estado. Se o estado muda, ele deixou d ser quem era.

Não entendi o que você chama de expor o domínio, e qual seria o problema de fazer isso. Mas quando há distribuição você compartilha assemblies?

Como você expõeserviços que interagem com o domínio sem expor o domínio? Ou expor o domínio pra você é uma mera questão de compartilhar assemblies?

Tem muita coisa estranha...

--

[icalmeida]

Se não pode referenciar diretamente a assembly de domínio para utilizar os enuns coloque-os em um outro assembly comum, as vezes temos um assembly para interfaces.

Agora quando a questão da distribuição em DDD somente distribua se realmente for necessário lembrando do que diz Martin Fowler no livro PoEAA "First Law of Distributed Object Design: Don’t distribute your objects!"

 

On Monday, July 2, 2012 4:16:55 PM UTC-3, Rennes wrote:

[Marcelo Vieira]

Vamos lá,

Daniel,
não entendi de onde você conseguiu tirar essa conclusão com relação ao meu entendimento sobre DDD;

Primeiro em momento algum eu citei sobre o conceito que define objeto de valor e entidade. Eu sei que o que define a entidade, como você mesmo citou, são suas características (olha que não estou falando técneis), comportamentos e sua identidade (a entidade depende de um dado que representa sua identidade), ela faz sentido para o negócio. Já o objeto de valor não (não faz sentido sozinho), ele é o que é, sua identidade é a soma de todos os seus atributos.

Quanto a "expor o domínio":
     - Expor o domínio é expor a inteligência/regra de negócio, seja disponibilizando as classes de domínio serializadas para o Client ou mesmo compartilhando seu assemblie. No caso nem sempre você quer expor essa inteligência/regras. Um banco financeiro por exemplo não vai querer expor acesso direto às classes de domínio, etc... Entendeu?

     - Consumir o domínio é por meio de serviços DDD (Não entenda esse serviço referido aqui como sendo os de WCF).

     - Você tem, geralmente, 3 alternativas:
          1) ou você expõe o domínio distribuindo-compartilhando o assemblie de suas classes para a View (Client) acessar diretamente;

          2) ou você disponibiliza uma "cópia" (você viu que está entre aspas?) serializando essas classes (mas note que nesse caso tem alguns percalços) por meio de serviços WCF;

          3) ou você distribui os ....dados/informação.... por meio de DTO/Model (model do MVVM por exemplo), por meio de SERVIÇOS DE APLICAÇÃO (camada do DDD) -- Note que não falei SERVIÇO DE COMUNICAÇÃO (WCF, que fica na camada de INFRA do DDD, usada também pela View (camada do usuário) ),

RESSALVA:
     - Se for usar o WCF (no qual eu recomendo pelo poder que ele oferece na implementação da "computação distribuida"), então as classes DTO/Model podem ser serializadas por ele para serem usadas no Client, ou você pode disponibilizá-las em um assemblie separado (mesmo usando o WCF) ao invés de serializá-las.

CONCLUSÃO:
     - Consumir o domínio por meio de SERVIÇO DE APLICAÇÃO (por meio ou não de serviços WCF) comunicando (trafegando) as informações em DTO/Model, então o domínio NÃO (NÃO) estará exposto. -- Se assim for do desejo dos STAKEHOLDERs.

     - Foi isso que propus ao Rennes. Mas com um detalhe a mais, que ele separasse as classes de objetos de valor em outro assemblie e este então seria exposto (compartilhado ou serializado) para as User Interfaces. Poderia ainda essas classes ficarem juntas no mesmo assemblie que estariam sendo distribuídos os DTO-/Model.

Bem.. acho que não tem mais nada estranho! rs

Marcelo Vieira

Para postar envie uma mensagem para dotnetarchitects@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitects+unsubscribe@googlegroups.com

[Marcelo Vieira]

É isso ai!!

[Hugo Estevam]

Marcelo,

 

Ainda achei algo estranho:

 

1) "Note que não falei SERVIÇO DE COMUNICAÇÃO (WCF, que fica na camada de INFRA do DDD, usada também pela View (camada do usuário) )"

Tem certeza que os serviços de comunicação ficam na Infrastructure Layer? Não seria na Interface Layer por se tratar de um web service ou afim?

 

2) "Consumir o domínio por meio de SERVIÇO DE APLICAÇÃO (por meio ou não de serviços WCF) comunicando (trafegando) as informações em DTO/Model"

Não acha que se o serviço da aplicação consumir DTO eles vão ficar dependentes do DTO? Se você tem uma aplicação web MVC e outra mobile em Android por exemplo, ao colocar o DTO na camada de aplicação você está forçando as duas aplicações a utilizar, sendo que de fato só uma necessitaria. Vejo que os DTOs e a entidade responsável pela sua serialização deles devem ficar na Interface Layer, ou seja, só quem necessita de distribuição usa.

 

Aqui tem um código de exemplo clássico, demonstra bem o que cada camada possui (em Java): http://dddsample.sourceforge.net/characterization.html

 

Um abraço,

Hugo Estevam

[Marcelo Vieira]

Olá Hugo,

- Quanto ao item (1) você tem razão, a camada de INFRA (no DDD) cuida da base estrutural para servir em especial às camadas de domínio e de serviço de aplicação, é a base da "nuvem", são os servidores.
Eu tinha citado INFRA também no sentido TRANSVERSAL, a parte de "infra" de comunicação que fica no Client, ou como você melhor disse na Interface Layer, no caso do WCF nos Clients se usa os ChannelFactorys, as configurações de binginds dos endpoints no arquivo app.xaml.

- Quanto aos serviços de aplicação ficarem dependentes dos DTOs, no cenário que citei ficariam sim dependentes. Mas conforme já foi postado aqui nessa thread de discussão, a arquitetura ideal varia conforme a necessidade, situação e contexto da aplicação. No meu caso eu tenho uma aplicação que sei que será somente usada/consumida por meio de serviço de comunicação WCF com ENDPOINTs usando "HttpBinding" e "netTcpBinding" somente. Citei esse cenário em função da minha respota ao Daniel.

Grato pelas observações!

Marcelo Vieira

[Marcelo Vieira]

Correção: as configurações de WCF em arquivo no Client, ficam no arquivo app.config e não "app.xaml" (Nota: mas esse nome app.config pode ser mudado também).