BFF — Não largue seu best friend forever
O conceito de BFF — da sigla em inglês para best friend forever- é o seu melhor amigo. Mas em relação a aplicações mobile o objetivo aqui é facilitar a manutenção das mesmas, sendo uma camada intermediária entre o backend e o frontend. Imagine que temos a seguinte tela abaixo:
São muitas as informações a serem exibidas na tela, e perceba que algumas informações são dinâmicas, como o número de cupons, o resumo de valores, entre outras. Se formos desenvolver uma variante deste sistema para rodar em mais de uma plataforma (por exemplo, iOS, Android, windows) imagina que teríamos a regra da soma do valor com a taxa de entrega repetida inúmeras vezes. Caso algum desenvolvedor fizesse alguma alteração inadvertida, pode ser que para alguns usuários o valor total da compra viesse errado. Vamos imaginar que por algum motivo a opção de doação para ação da cidadania devesse ficar inativa, ou ainda que seus valores fossem alterados para R$5, R$10 e R$15. Percebe aonde desejamos chegar? Já é interessante que coloquemos as regras de negócio da aplicação em um lugar centralizado, mas podemos estender para que todas as regras aplicáveis a objetos visuais (sejam eles textos e alguns outros componentes) também fiquem centralizadas, facilitando a manutenção e os testes. Parece uma estratégia simples, e apresenta um ganho gigantesco em agilidade, testabilidade e qualidade.
Detalhando o exemplo acima, vamos utilizar os campos do resumo de pagamento e um possível mapeamento na nossa aplicação:
var amount: Double = 20.0
var transferTax: Double = 5.0
var totalAmount: Double = amount + transferTaxPerceba que aqui estamos com a regra que calcula o valor total do pedido direto no aplicativo, bem como podemos ter algum problema de arredondamento dados valores específicos. Gosto de ir a fundo nas regras que estão ocorrendo aí.
var amount: Double = 20.0Somente neste campo, temos 3 regras aplicáveis. A formatação do mesmo, a moeda a ser utilizada e o arredondamento do valor. Padronizar o arredondamento do valor é simples, basta pedir que já venha arredondado e nenhuma regra seja aplicada no frontend. Para a formatação e moeda a ser utilizada, a coisa complica um pouco. Podemos ter algo como "20 reais" ou "R$20,00" ou ainda "$20". Por esse motivo que é interessante trocar o tipo do campo para string, e toda essa lógica de formatação também fica agnóstica ao nosso aplicativo.
var amount: String = "R$20,00"Caso seja necessário trocar para outra formatação, o nosso aplicativo não precisa se preocupar, porque uma troca no BFF já resolve para todos os consumidores do serviço. Nesse caso estamos deixando todas as regras desta seção no BFF que pode devolver algo neste sentido:
var amount: String = "RS20,00"
var transferTax: String = "R$5,00"
var totalAmount: String = "R$25,00"Veja que isso facilita também a implementação de acessibilidade, uma vez que o leitor de telas só precisará ler o valor presente no campo e muito provavelmente já entenderá algo como "25 reais".
As regras de negócio presentes na seção de doações são implícitas. Imagino que aqui a quantidade de valores disponíveis para doação (bem como sua negativa, representada na opção "agora não") pode mudar, e também cada um dos valores. Outra possibilidade é não existir a seção de doação, pelo motivo do fim da campanha. Essas são decisões que pessoas podem tomar de maneira arbitrária então facilita se fizermos algo como:
{
"donations": [{
"donationValue": 0.0,
"donationName": "Agora não"
}, {
"donationValue": 2.0,
"donationName": "R$2,00"
}]
}Temos os valores para poder passar para frente bem como os textos dos botões em uma lista. Para adicionar uma nova opção, basta adicionar um elemento na lista, por exemplo. Imagina o trabalho que daria para subir uma nova versão do aplicativo na loja (e passar pelo review das lojas) só para alterar um valor dentre os disponíveis para doação?
🤔 Pera, mas aí você está adicionando uma regra a mais no frontend para somar o valor da compra com o valor da doação? Não será necessário. No momento de enviar os dados a fim de efetivar a compra podemos enviar dois campos, um "amount" com o valor da compra e outro "donationAmount" com um dos valores presentes na listagem acima. Muito provavelmente os valores vão para lugares diferentes e isso já facilita para o cara que desenvolve a parte transacional no servidor.
Perceba que tudo isso apresentado acima não depende de nenhuma biblioteca especial, muito menos de nenhuma arquitetura de software específica. O que estamos fazendo aqui é centralizar as verdades da aplicação e suas regras de negócio. (Tem um artigo falando sobre bugs e verdades aqui.) de modo a facilitar a manutenção do software no dia a dia. Bom desenvolvimento!
