Há alguns anos, Alistair Cockburn propôs um padrão bem interessante. Citando suas palavras, a ideia central é:
Permitir que a interação com uma aplicação seja idência para usuários, programas, testes automatizados ou scripts. Também, que possa ser desenvolvida e testada isoladamente.
Na medida que “eventos” cheguem de componentes externos, seria responsabilidade de um adaptador fazer a conversão para uma chamada local ou mensagem a ser encaminhada para a aplicação. Esta seria ignorante a natureza da origem do input. Quando a aplicação tem algum retorno ou necessidade de envio externo, também o faria através de um adaptador que usaria os meios apropriados para cada tecnologia. A aplicação “conhece” apenas os adaptadores, sem jamais interagir com componentes externos diretamente.
Poderíamos representar essa ideia graficamente da forma que segue:
De acordo com este padrão, é uma boa ideia projetar nossas aplicações com algum nível de separação entre o core, que contem a lógica de domínio, e uma camada externa de adaptadores que seriam responsáveis por interagir com componentes externos. Seguindo essa idia, controllers Web API/MVC seriam bons exemplos desses adaptadores – eles são responsáveis por prover data e por tratar inputs. O mesmo pode ser dito a respeito de implementações do padrão Repository que interage com bases de dados.
Enquanto algumas abstrações são interessantes no modelo de dominio, estas podem não ser adequadas para interação com componentes externos. A camada externa, que contem as implementações dos adaptadores, seria onde as abstrações do domínio seriam convertidas para representações mais adequadas.
Um bom exemplo das implicações desse padrão seria a adoção de um modelo separado para persistência sempre que necessário. Outro bom exemplo é o uso de DTOs na comunicação com o frontend.
Adotar este padrão reduz o acomplamento e torna o sistema mais fácil de manter. No curto prazo, ele poderia aumentar os custos de desenvolvimento. Entretanto, o custo se justificaria facilmente no longo prazo.
