Como alinhar sua API às operações de Negócio?

Actualmente é comum construir uma API com operações granulares. Nessa abordagem, cada endpoint executa uma operação relacionada a uma tabela ou entidade de negócio.
Essa abordagem é válida, quando se trata de softwares simples, prototipagem ou provas de conceito.

Cenário Ideal

De acordo aos padrões de design e arquitetura mais conhecidos um componente de software, classe, endpoint deve fazer uma coisa e se possível ser micro, apresentando exemplos simples ou cenários de big techs como caso de estudo.

O problema dessa abordagem é a chamada de vários enpoints para resolver uma operação de negócio.

Praticamente a API é orientada a CRUD sobre tabelas da base de dados, não representando regras de negócio completas.

Tratando-se de uma API são várias chamadas na rede, aumentando o tempo de resposta de uma operação. Em grande escala isso pode ser desvantajoso.

Cenário Real

Em sistemas com complexidade real de negócio, é comum as operações refletirem um processo de negócio. Raramente existem operações isoladas. Cada operação interliga ordenadamente várias entidades centrais relativas a regra de negócio.

Para facilitar a compreensão é necessário fornecer os dados de entrada necessário para que uma operação aconteça.

Vantagens

• Pouca interferência da rede.
• Melhoria no tempo de resposta da API.
• Rastreabilidade das regras de negócio.
• Centralização da lógica da operação.
• Facilidade de Debug.

Exemplo

O Reajuste salarial pode seguir o seguinte fluxo:

• Entrada dos dados do reajuste: funcionário e valor.
• Verificação do funcionário: existência do funcionário.
• Validação do ajuste funcionário: valor mínimo, valor máximo, último prazo do reajuste.
• Armazenamento do reajuste numa tabela.
• Armazenamento do histórico de reajuste: salário anterior, novo salário, responsável, data da mudança, tipo de reajuste e usuário responsável

No endpoint /api/reajuste é necessário fornecer os dados necessários para o processamento dos dados, sem a necessidade de outro endpoint complementar.

Resultado

A API torna-se mais objectiva e orientada a regras de negócio. Notamos que uma operação pode seguir um fluxo ou parte essencial do fluxo, reduzindo a necessidade de várias chamadas.
O Front-end apenas fornece as entradas necessários e o Back-end, se possível executa uma operação de negócio completa.