ASP.NET Core 3.1 - Payment API - Anti-Corruption Layer and Façade Pattern (Parte 15)

A API de Pagamento que eu criei, possui a implementação do padrão de projetos da anticorrupção (Anti-Corruption Layer Pattern). Juntamente com esse padrão, eu aproveitei e apliquei o uso do padrão façade (façade pattern).

Anti-Corruption Layer Pattern

Esta camada não está diretamente ligada ao uso de microsserviços, mas ela ajuda na solução de alguns problemas e na melhor forma de portar um sistema legado para novas estruturas sem que haja necessidade de uma migração completa, a imagem que está na documentação da Microsoft a seguir demonstra esta conexão com isolamento de outros sistemas ou microsserviços.

AntiCorruption Layer Diagram

Veja também o que diz o Eric Evans:

When systems based on different models are combined, the need for the new system to adapt to the semantics of the other system can lead to a corruption of the new system’s own.

The underlying concept is pretty clear. When we need to "talk" with other system, data repository or legacy code (even "ours" legacy code) we should prevent our model from other "foreign models".

Mas e o que tudo isso tem a ver com a API de Pagamento?
A API de Pagamento se comunica com outros sistemas, cartão de crédito, débito, boleto, sistemas legados, entre outros. Cada um desses sistemas ou subsistemas, possui modelos (models) distintos e eu não gostaria que eles fizessem parte do domínio principal, por isso esta camada foi criada, além disso cada um dos modelos dos meios de pagamento são traduzidor para o modelo padrão da API, ou seja um modelo único com as informações necessárias requeridas.

Podemos ver esta definição de uso a seguir.

If your application needs to deal with a database or another application whose model is undesirable or inapplicable to the model you want within your own application, use an Anticorruption Layer to translate to/from that model and yours.

Façade Pattern

Sobre esse padrão, o dofactory diz:

Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.

E o que a façade tem a ver com a API de Pagamento?
A façade neste caso possui uma única interface, uma interface de alto nível que dependendo do meio de pagamento realiza uma ação ou outra. O objetivo da façade é diminuir o acoplamento e limitar a manutenção a um único ponto. Digamos que o sistema de emissão de boletos mude, como ocorreu recentemente com a obrigatoridade de registro do boleto, o ponto de mudança é único e isso não afeta nenhum dos outros sistemas que utilizam a API de Pagamento. Isso também serve para a camada anticorrupção, caso haja alguma mudança de algum meio de pagamento, uma atualização de versão, como acontece frequentemente com a emissão de nota fiscal eletrônica, a única mudança a ser feita é na camada anticorrupção, nenhum outro sistema seria influenciado.

Class Libraries

Crie 2 projetos para separar as implementações e as interfaces (contratos):
1 - Payments.AntiCorruption
2 - Payments.Business

AntiCorruption

É a class library onde fica a implementação dos métodos com as regras de negócio de cada tipo de pagamento.

Business

É a class library onde ficam as regras de negócio relacionadas ao pagamento como um todo e as interfaces com a assinatura dos métodos que são implementados na camada anticorrupção.

A imagem a seguir mostra a estrutura.

Class Libraries

Você pode explorar o conteúdo das classes através deste link ou então baixar o projeto do Github e ver como a controller de pagamento realiza a chamada e navegar pelo funcionamento.

Continua na Parte 16.