É uma boa ideia adicionar o ViewModel exatamente igual ao Model

Tenho as seguintes camadas na minha solução:

1. App.Domain
2. App.Service
3. App.Core (talvez você chame este de App.DataLayer)
4. App.Web

O padrão de design de software não é minha pergunta. Tenho o seguinte modelo Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Quero usar esse modelo na visualização (por exemplo, página inicial) E quero usar Id, Name & Value, portanto, se eu quiser criar o ViewModel, adicionarei o seguinte:

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Então, essa é uma boa ideia? ou apenas usar em Foovez de FooViewModel?

Isso pode parecer uma violação da regra DRY inicialmente, mas eu argumentaria que "código semelhante e até idêntico" não é necessariamente "repetição" se fizer algo diferente ou puder mudar de forma independente. E no caso dos modelos de visualização, o código está definindo o que o "cliente" vê, não necessariamente as entidades e operações sobre as quais o negócio fala. Portanto, você costuma revelar modelos para o cliente ou interface que são "incidentalmente idênticos". Você pode alterar as regras e os termos comerciais ou a terminologia do usuário final independentemente um do outro.

Então, eu voltaria a pergunta para você. Se o domínio mudar, é aceitável que os clientes da "versão 1" continuem usando as interfaces antigas? Você nunca revelará termos ou operações na interface que não fazem parte das "principais regras de negócios?" E vice versa?

Esse tipo de pergunta em mente, se a "função" da sua exibição é estritamente para revelar o modelo de domínio subjacente, sim, isso parece violar a regra DRY.

_{Também tenha em mente, expor uma visão que muda mais naturalmente com as alterações do modelo também pode ser realizada em alguns idiomas com atributos e reflexão dos membros. (Ou com menos repetição em outros feitos de esperteza ... Mas, "esperteza" geralmente falha em justificar a repetição que ela poupa.)}

Eu teria um modelo de exibição que continha apenas uma propriedade, uma instância do Foo. Dessa forma, você não está violando o DRY de acordo com qualquer definição, se o Foo mudar, seu modelo de visualização verá a alteração automaticamente e você ficará livre de uma ligação direta do modelo de visualização ao modelo.

Se amanhã for necessário que o view mostre algo mais, além do Foo, você pode simplesmente adicionar uma nova propriedade, e a intenção do seu modelo de view ainda será clara, ele contém um Foo e algo mais, você não terá uma mistura de propriedades da Foo com outras propriedades não relacionadas.

Eu não pensaria no seu modelo de visão como um FooViewModel, pensaria nele em termos do que a visão deveria exibir. Se ele exibir apenas um Foo, o modelo de visualização conterá uma propriedade, um Foo.

Não tenho certeza se expliquei isso claramente. Caso contrário, avise-me e tentarei reformulá-lo quando estiver acordado!

Eu diria que o uso FooViewModeldessa maneira viola o princípio DRY. Quando você precisa fazer uma alteração, Footambém precisa fazer uma alteração FooViewModel. Eu acho que você seria melhor servido simplesmente usando Foocomo modelo para a sua opinião. Eu consideraria um modelo de exibição se você precisar exibir coisas do Foo e outras coisas. Por exemplo, digamos que você precise renderizar algumas informações de Fooe também de Bar.