> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2020/w27-domain-driven-design-and-frontend-backend-interaction-patterns.md).
# W27-Design orientado a domínio e interação entre frontend e backend
#### **Algumas reflexões sobre design orientado a domínio**
**Como manter estável o núcleo de um projeto em meio a mudanças rápidas, sem deixar a complexidade crescer até exigir uma reescrita?** Já enfrentamos perda de conhecimento de negócio na comunicação dentro da equipe. Com o crescimento e a troca de pessoas, isso só tende a piorar. **O que é esse núcleo? A compreensão e a abstração do negócio. Traduzidas em design de software, acho que correspondem ao design orientado a domínio.**
Em comparação com o frontend, o backend costuma ter um projeto mais detalhado e de horizonte mais longo. O projeto precisa partir de uma compreensão profunda do negócio. Quanto mais profunda a compreensão e completa a abstração, melhores a manutenibilidade e a capacidade de expansão. Em certo sentido, sem um projeto, o backend talvez nem consiga começar.
No frontend, é diferente. Nossas propostas técnicas tratam mais de pontos técnicos isolados e da implementação dos fluxos de negócio. Ainda decompomos pouco o negócio em profundidade. Francamente, **nosso projeto de soluções ainda se concentra na implementação orientada a páginas**. Raramente vemos uma abstração do negócio que determine a estrutura de componentes e camadas do software.
Em um bom backend, as tabelas e a camada de serviços são relativamente estáveis graças à compreensão e à abstração do domínio. O lado dos comerciantes está em uma fase de iteração rápida, e a interface e as interações também mudarão depressa. Como responder a muitas mudanças mantendo uma base estável? Como sustentar o crescimento do negócio com menor custo total? Quero encontrar respostas no design orientado a domínio.
No checkout, a refatoração da versão i organizou o aplicativo em componentes contêineres e componentes de apresentação. Os contêineres cuidam do estado e da lógica de negócio; os de apresentação são componentes puros que mapeiam dados para a interface. A lógica de frontend do checkout não é muito complexa, mas o contêiner já tem mais de 600 linhas. Ainda parece limpo, porém logo receberá pagamento com crédito, recursos de investimento e marketing. Ficará cada vez maior. Precisamos dividi-lo. Como? Por domínio. O núcleo do frontend do checkout é o tratamento dos meios de pagamento, que devem ser abstraídos conforme suas características de negócio. Cada meio corresponde a um provedor de ativos diferente e pode ser entendido como um domínio. Cada domínio tem atributos e comportamentos próprios. Pagamento rápido tem uma lista de cartões e a ação de selecionar um cartão para informar a senha. Pagamento com crédito tem número de parcelas e valor, reconhecimento facial para contratar crédito e obtenção do contrato. Esses elementos estão na base da lógica e são relativamente estáveis. A interface pode mudar, mas o núcleo, a camada de domínio, permanece. Mesmo uma troca de Vue por React pode preservar esse núcleo na migração.
Eu também fui fraco nesse aspecto do design. As ideias sobre domínio ainda precisam de conversa e confronto de perspectivas para evoluir.
#### **Algumas impressões sobre a troca de dados entre frontend e backend**
Em comparação com a carteira, os produtos de pagamento têm diferenças claras no desenho da interação entre interfaces. Em checkout, vinculação de cartão e pagamento da conta, as APIs oferecidas ao frontend são basicamente orientadas a páginas. Sua relação segue exatamente a sequência da interação humana. A chamada anterior retorna a URL da próxima, seus parâmetros e tudo o que a página atual precisa. Só falta devolver a própria página renderizada.
A vantagem é que o frontend se concentra quase só na interação com o usuário, com uma responsabilidade aparentemente simples. O backend tem flexibilidade para controlar a sequência, escolher as próximas interfaces, chamar serviços diferentes e retornar dados sem negociar com o frontend.
A desvantagem também é clara. O modelo acopla fortemente a API à interface, ou ao fluxo de interação, e é frágil em extensibilidade. Ele funciona porque a interface e os processos de negócio são suficientemente estáveis. Os pagamentos de fato atendem razoavelmente a essa condição. Embora o modelo tenha pouca generalidade, sua escolha na arquitetura de pagamentos deve refletir considerações mais profundas. Por enquanto, nesse contexto, não consigo classificá-lo como absolutamente bom ou ruim. Preciso aprender no trabalho.
**No projeto de pagamento rápido, a interface A informa e determina a chamada seguinte. O backend precisa conhecer a versão do frontend, seja pelo número de versão, seja por uma liberação gradual de ponta a ponta guiada pelo identificador do cliente.**