Cada camada seria equivalente a uma máquina para cada parte da aplicação? 
Temos dois tipos de camadas: Tiers e Layers.
Os tiers podem ser máquinas (VM’s) diferentes.
Dentro de um tier você pode dividir sua aplicação em layers. Uma aplicação web comum pode ter dois tiers: computador do usuário (html) e o servidor. Dentro do servidor você pode dividir a aplicação em layers (ex: MVC).
Esclarecendo 
Não necessáriamente deve ser uma máquina rodando Java.
Pode ser por exemplo um servidor de fonte de dados.
No caso genérico, tiers implicam processos diferentes, que podem ou não estar no mesmo computador.
Sobre tier vs. layer: http://en.wikipedia.org/wiki/Multitier_architecture
“The concepts of layer and tier are often used interchangeably. However, one fairly common point of view is that there is indeed a difference, and that a layer is a logical structuring mechanism for the elements that make up the software solution, while a tier is a physical structuring mechanism for the system infrastructure.”
Infelizmente, não há tradução comumente aceita de tier para o português, então frequentemente tier também é traduzido como camada.
Na verdade, podemos traduzir layer como “camada lógica” e tier como “camada física”. Chamar tudo de camada sem diferenciar acaba criando confusão.
[EDITADO]Não consigo dar “quote” na mensagem. Alguém sabe se o JFórum está com problema?[/EDITADO]
É… eu cogitei usar esses termos mas mudei de idéia porque “camada física” é um termo consagrado como a camada de mais baixo nível do tradicional modelo OSI, e pode causar até mais confusão.
É… eu cogitei usar esses termos mas mudei de idéia porque “camada física” é um termo consagrado como a camada de mais baixo nível do tradicional modelo OSI, e pode causar até mais confusão.
[/quote]
O jeito é colocar nota de rodapé :lol: .
Eu costumava chamar “layer” da camada e “tier” de nó. Mas acredito que é melhor ficar na definição em inglês.
Enfim, “tier” é um processo, podendo vários deles rodarem na mesma máquina ou não.
“Layer” é só uma maneira de dividir o sistema para controlar as dependências entre objetos. Exemplo: está-se separando o sistema em “layer” de negócio e “layer” de aplicação, onde o primeiro conhece o segundo, mas não o inverso. Então, na sua estrutura de classes, esse comportamento também deve ser mantido, ou seja, classes do layer de aplicação não podem depender (por herança ou associação) de nenhuma classe do layer de negócio.
Mais uma coisa, MVC não tem nada a ver com camadas. É só um pattern para representar um modelo ao mundo externo, que é útil para apresentar interfaces gráficas ao usuário ou apresentar documentos (em XML, JSON, ou outros) que sejam consumíveis por outros processos.