Eu praticamente respondi em https://pt.stackoverflow.com/q/362345/101.
DTO, como o próprio nome diz, é um objeto com dados sendo transferidos entre memória e persistência. Ele costuma ser uma classe com todos os campos de um modelo e geralmente não tem comportamentos, só estado. Pode ser grande e complexo e não costuma ter identidade, ou seja, se mudar algo nele, tudo bem, continua sendo o mesmo objeto, portanto semântica típica de referência. Por exemplo, um cliente ou produto poderiam ser representados em determinado momento da aplicação com o DTO. É um objetivo de mecanismo.
Value Object é algo bem mais simples e que representa um valor único, por exemplo um telefone, um e-mail, uma quantidade. Ele tem identidade e mudar alguma coisa nele passa ser outro objeto, portanto semântica típica de valor. Nas linguagens que permitem, de fato ele é por valor e não uma classe. Há casos que pode ter comportamento.
Isto pode ajudar entender embora não seja a mesma coisa: https://pt.stackoverflow.com/q/16181/101. Há uma relação conceitual entre a classe e o DTO e a estrutura e o VO, não que elas precisam estar ligadas, até porque tem linguagem que sequer tem struct.
Model sem contexto, sem um complmento da expressão fica complicado dizer, pode não ter tanta relação.
Algumas pessoas vão usar isso como o agregador de entidades e value objects. Ou seja, precisaria entrar em um capítulo de um livro para explicar todas as relações, já que esses termos não têm tanta relação assim.
Pode estar usando o model como a definição da entidade e a relação do DTO é um intermediário entre a entidade e a comunição externa à aplicação.
Eu não trataria essas coisas como camadas. Eveuntualmente elas se relacionam, mas não vejo como camadas. E se fizer provavelmente está fazendo over engineering.
Faz sentido para você?
Espero ter ajudado.
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).