Design orientado a domínio e arquitetura de serviços WCF

5

Estou tentando descobrir como arquitetar meu projeto no paradigma DDD (um iniciante completo em DDD) e deparei com um problema sobre a implementação dos serviços da Web ... Essas são algumas opções que vejo:

Fat client, servidor Fat (opção 1):

  • Servidor:
    • Camada de repositório: conversa com o banco de dados e pode retornar objetos de domínio.
    • Camada de domínio: contém objetos de domínio com lógica de negócios e validações.
    • Camada de serviço: age como uma fachada na camada de domínio.
    • Camada do WCF: expõe a camada de serviço aos métodos da Web. Ele mapeia objetos de domínio para objetos DTO apropriados.
  • Cliente:
    • Camada de infraestrutura: conversa com o servidor através dos serviços do WCF. Ele mapeia objetos DTO de volta para objetos de domínio.
    • Camada de domínio: contém objetos de domínio com lógica de negócios e validações.
    • Camada de serviço: age como uma fachada na camada de domínio.
    • Camada de interface do usuário (WinForms): usa a camada de serviço para se comunicar com objetos de domínio.

Bom: como a camada de domínio está no cliente e no servidor, as validações ocorrem em ambos (bom para clientes - reduz o número de chamadas para o servidor, bom para o servidor - por causa de 'nunca confiar nos dados do usuário').

Ruim: validação acontece duas vezes, muito mapeamento necessário (por exemplo, uma consulta simples ao banco de dados: domínio (retornado pelo repositório) - > DTO (necessário para o WCF) - > domínio (necessário pela camada de domínio no cliente ) - > DTO (para WinForms). Qualquer mudança no domínio deve ser implantada no servidor e no cliente ao mesmo tempo. Complicado?

Fat client, servidor thin (opção 2):

  • Servidor:

    • Repositório: conversa com o banco de dados e retorna objetos DTO.
    • Camada do WCF: expõe as chamadas do banco de dados aos métodos da Web.
  • Cliente: Exatamente o mesmo que na opção 1.

Bom: no cliente, posso tratar os serviços do WCF como um repositório regular que retorna objetos DTO. Mais simples como a opção nr. 1.

Ruim: está certo que o repositório funcione em DTO-s em vez de objetos de domínio? Além disso, o servidor não executa nenhuma validação, portanto, ele deve confiar nos clientes sobre os dados.

Thin client, fat server (opção 3):

  • Servidor: Exatamente o mesmo que na opção 1.

  • Cliente:

    • Camada de infraestrutura: conversa com o servidor por meio de serviços WCF.
    • Camada da interface do usuário (WinForms): usa apresentadores para se comunicar com o servidor por meio de chamadas do WCF na camada de infraestrutura.

Bom: toda a lógica do domínio está no servidor.

Ruim: o cliente não contém nenhuma validação, por isso pode fazer muitas chamadas desnecessárias ao servidor.

Eu estou inclinado para a minha primeira opção, mas parece que estou complicando demais as coisas ... Algum conselho ou outras opções?

    
por sventevit 04.04.2014 / 12:36
fonte

1 resposta

2

Eu escolheria a Opção 3, com as seguintes notas:

  1. Tente reduzir a quantidade de lógica de domínio que seus clientes precisam saber para realizar o trabalho. Crie serviços que exponham esses dados de maneira significativa (para seus clientes), de modo que você possa solicitar coleções de objetos de domínio que atendam a determinados critérios, em vez de fazer isso processando seu cliente.
  2. A validação deve ser considerada opcional no lado do cliente, pois você nunca pode garantir que as futuras implementações do cliente serão feitas corretamente. Portanto, sempre valide no lado do servidor como se não tivesse sido feito em outro lugar. É claro que os clientes devem estar validando no lado do cliente também.
  3. Em vez de mapear os dados do WCF de volta para objetos de domínio completo no lado do cliente, considere mapeá-los para objetos do tipo ViewModel mais simples - uma versão enxuta de seus objetos de domínio completo contendo apenas propriedades apropriadas ao cliente - torna a programação do cliente mais simples .

O problema que você ainda enfrenta é muito mapeamento. Eu acho que esse preço vale a pena pagar (e facilitado com uma ferramenta como AutoMapper ) porque a remoção da dependência do cliente em seu modelo de domínio oferece respirando espaço para mudar seu domínio, ajustar o mapeamento, sem quebrar nenhum código do cliente.

    
por 07.04.2014 / 12:41
fonte