██FR█████ █INTELL███████████

Como Decidir pelo Uso de Camadas Anticorrupção


This content originally appeared on DEV Community and was authored by Alberto Luiz Souza

Disclaimer

Este texto foi inicialmente concebido pela IA Generativa em função da transcrição de uma live do Dev Eficiente. Se preferir acompanhar por vídeo, é só dar o play.

Introdução

Quando desenvolvemos sistemas, frequentemente precisamos decidir até onde devemos nos proteger de influências externas. Devemos sempre criar camadas anticorrupção para isolar nosso domínio? Ou existem situações onde essa proteção adicional não compensa? Neste post, vamos explorar justamente como podemos decidir sobre este tema.

O Que é uma Camada Anticorrupção?

Segundo o livro Domain Driven Design, uma camada anticorrupção é um meio de ligar dois contextos delimitados. A ideia central é que você tem dois contextos (ou sistemas) que precisam se comunicar, mas você quer limitar a influência de um sobre o outro.

Embora o livro foque muito na comunicação entre serviços em contextos diferentes, na prática acabamos aplicando esse conceito em várias situações, como em nossas APIs web.

Exemplo Prático: APIs Web

Vamos considerar um exemplo comum: um controller que recebe requisições HTTP.

@PostMapping("/clients")
public void create(ClientRequest request) {
    // converte request para entidade Client
}

Por que não recebemos diretamente a entidade Client como parâmetro? Por que criamos essa classe ClientRequest?

Há várias razões, incluindo segurança (lembra do caso de invasão do GitHub através de mass assignment?), mas fundamentalmente, ClientRequest funciona como uma camada anticorrupção. Ela protege nosso domínio das eventuais mudanças que podem acontecer em relação aos dados que recebemos da aplicação cliente.

A Questão do Banco de Dados

A partir de uma aula da Jornada Dev+ Eficiente, onde eu comento que não é fácil se isolar da sua escolha de banco de dados, um aluno questionou, e exemplificou, que dava sim para fazer um código isolando sua entidade de domínio das suas entidades do banco de dados.

Sem dúvidas, existe um caminho para amenizar a influência. Você poderia ter:

  • Uma classe Client representando sua entidade de domínio (sem anotações JPA)
  • Uma classe ClientEntityDatabase representando a entidade do banco de dados
  • Conversores entre as duas 
// Entidade de domínio pura
public class Client {
    private String code;
    private String email;
}

// Entidade do banco de dados
@Entity
@Table(name = "clients")
public class ClientEntityDatabase {
    @Id
    private Long id;
    private String code;
    private String email;
}

E por que eu não uso essa abordagem por default?

O Critério da Estabilidade

Na minha visão, a decisão de criar ou não uma camada anticorrupção deve considerar principalmente a estabilidade do sistema com o qual você está se integrando.

Sistemas Menos Estáveis (Use Camada Anticorrupção)

  1. APIs Web/HTTP: Os payloads tendem a inflar com o tempo, parâmetros extras aparecem (confirmação de senha, confirmação de email, etc.) etc.

  2. Integrações com Parceiros Externos: Como no exemplo do Typeform citado no vídeo, onde foi criado um serviço de camada anticorrupção para abstrair o sistema de formulários, facilitando uma eventual troca para Google Forms ou outro provedor.

  3. Sistemas que Você Não Controla: Qualquer integração onde mudanças podem acontecer sem seu controle direto.

Sistemas Mais Estáveis (Camada Anticorrupção Pode Ser Desnecessária)

O banco de dados tende a ser o sistema mais confiável e estável que sua aplicação interage. Além disso, em geral, ele tende a ser escolhido dentro de um conjunto de opções já estabelecidas pela organização.

Dentro deste contexto, e se tiver tecnologia que facilite, considero que pode ser ok deixar o código ser influenciado pelo banco de dados escolhido. Afinal de contas, várias vezes nossa aplicação é “database driven” mesmo.

Exceções à Regra

Existem situações onde mesmo com bancos de dados você pode querer essa separação:

  • Quando usa tecnologias sem bom suporte de mapeamento para entidades de domínio (como Datomic em Java)
  • Quando o mapeamento direto realmente compromete seu modelo de domínio

Conclusão

A decisão de implementar uma camada anticorrupção não deve ser automática. Ela deve ser baseada em:

  1. Quão estável é o sistema que você está integrando?
  2. Quanto controle você tem sobre mudanças nesse sistema?
  3. Qual o custo/benefício da complexidade adicional?

Para requisições HTTP e integrações externas, a resposta geralmente é sim – crie a camada anticorrupção. Para bancos de dados e tecnologias que você escolheu como canônicas em sua organização, a resposta pode ser não – aceite a influência e aproveite as ferramentas disponíveis.

O importante é tomar essa decisão conscientemente, baseada nas características específicas do seu contexto.

Dev+ Eficiente

Se você gostou deste conteúdo, conheça a Jornada Dev + Eficiente, nosso treinamento focado em fazer com que você se torne uma pessoa cada vez mais capaz de entregar software que gera valor na ponta final, com máximo de qualidade e eficiência.

Acesse https://deveficiente.com/oferta-20-por-cento para conhecer tudo que oferecemos.


This content originally appeared on DEV Community and was authored by Alberto Luiz Souza