Nota do autor: Eu sou o autor do material sobre Action-Domain-Responder referenciado neste artigo.

Em seu texto sobre alternativas ao MVC (incluindo Action-Domain-Responder), Anthony Ferrara faz uma afirmação que é o centro de sua discussão. Embora eu concorde com muito do que ele diz nesse artigo e em outros artigos relacionados, acredito que a queixa seja um erro, e por mais que isso não traga nenhum demérito ao artigo como um todo, ao mudar a reivindicação errônea por uma correta deixa o estudo com um “tempero” diferente.

O erro central, na minha opinião, é que Anthony está perto do fim deste texto, no qual ele afirma (ao falar sobre MVC, ADR etc.) que “todos pretendem ser arquiteturas de aplicativos”. Essa afirmação me parece incorreta.

Embora os desenvolvedores que usam MVC possam pensar equivocadamente em MVC como uma arquitetura de aplicativo, sua própria descrição não faz tal afirmação. Na verdade, Fowler categoriza o MVC como um “Padrão de Apresentação Web” e não como um “Aplicativo de Arquitetura” por si.

Claro, o MVC está descrito no livro chamado “Padrões de arquiteturas de aplicação corporativas”, mas o próprio MVC é um padrão de apresentação dentro de uma arquitetura de aplicação. Aqui está outro exemplo distinto: nós não chamaríamos “Gateway de tabela de dados” de uma arquitetura de aplicação, mesmo que essa distinção também apareça no mesmo livro. É um padrão de fonte de dados dentro de uma arquitetura de aplicação.

A categorização e a descrição do MVC de Fowler o definiu muito claramente como um padrão de interface de usuário. O ADR, como um refinamento do MVC, é também um padrão de interface de usuário. Nem é uma arquitetura de aplicação em si mesma, apesar de serem a parte mais externa de uma arquitetura de aplicativo. Então, quando o artigo de Anthony afirma que o ADR “de acoplamento do HTTP torna difícil fazer uma interface não-HTTP”, a minha resposta é “Bem, obviamente – é um padrão de interface de usuário centralizada em torno do HTTP”.

Anthony então continua a dizer:

E essa é a maior razão pela qual todos esses “padrões”, “arquiteturas” e “conceitos” são uma piada de mau gosto. Eles resolvem o problema fácil, mas jogam o problema mais difícil por cima da cerca.

MVC, ADR etc. resolvem o problema de interface do usuário. Isso pode ser um problema fácil de resolver para Anthony, mas para dizer que os padrões de interface do usuário “jogam o problema difícil por cima da cerca” me parece ser a premissa de um conjunto errado de expectativas. MVC e ADR, assim como padrões de interface do usuário, não estão supostamente lidando com a lógica de negócios do núcleo, em primeiro lugar.

Talvez seja melhor dizer que a aplicação subjacente, que é apresentada através da interface do usuário, não é realmente o problema da interface do usuário em primeiro lugar. O código de interface do usuário provavelmente não deve se preocupar muito com o funcionamento interno do código do aplicativo subjacente. Se isso acontecer, então o código do aplicativo está borbulhando muito longe na interface do usuário.

Em resumo, eu acho que a afirmação de que “tudo pretende ser arquitetura de aplicação” simplesmente não é uma categorização precisa. Seria mais correto dizer que “todos são padrões de interface de usuário, e não arquiteturas de aplicação inteiros” – ou, melhor ainda, que “os desenvolvedores frequentemente não os entendem para que sejam arquiteturas de aplicação”.

***

Paul M. Jones faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://paul-m-jones.com/archives/6079