A gente já tem um escopo, a gente já está ganhando forma nessa história. Vamos chegar então, o que eu quero atingir com aquilo? Eu estou resolvendo um problema. Para eu resolver o problema, qual é o meu objetivo com isso? Só que além dos objetivos, a gente tem o que não é objetivo. E essa é uma das partes talvez mais difíceis de escrever, porque normalmente a gente pensa, beleza, eu vou fazer isso. A gente pensa no que eu não vou objetivo. E essa é uma das partes talvez mais difíceis de escrever, que normalmente a gente pensa, beleza, eu vou fazer isso. A gente pensa no o que eu não vou fazer. Quando eu estou criando essa solução, o que eu não vou fazer? E aí eu vou mostrar como fazer isso na prática. A gente pode, por exemplo, falar eu não vou incluir uma solução para atender o fluxo A, mas a minha solução atende o fluxo B e C. Isso daí eu estou deixando fora de escopo uma parte do meu sistema. Isso é bom estar documentado ali. Inclusive, para não criar uma expectativa de que embaixo, na hora que eu estiver lendo o resto dos documentos, eu vou encontrar a resposta para aquilo. Então, assim, enquanto os objetivos são requisitos de negócio ou técnicos que são alcançados com a conclusão daquela tarefa, então, assim, se eu fizer isso, o que eu atinjo? Eu vou ter um número maior de clientes? Eu vou ter, igual nesse caso que a gente está falando do payload, o payload eu atinjo? Eu vou ter um número maior de clientes, eu vou ter, igual nesse caso que a gente está falando do payload, o payload vai reduzir. E quando eu falo de fora de escopo, e aqui eu coloquei como se fosse uma seção única, você pode fazer uma seção única ou separar em duas seções, não tem problema. Como eu falei, é só, a gente está só passando por isso. Eu tenho como fora de escopo aqueles pontos que não vão ser contemplados. Porque às vezes você tem partes dos sistemas que vão continuar legadas e que não vão ser feitas alterações neste momento. E é aquele momento onde você fala, esse fluxo aqui não vai ser contemplado, ou essa parte do sistema eu não vou fazer, ou a gente está resolvendo esse problema e esse detalhe a gente está resolvendo esse problema e esse detalhe a gente não vai resolver. E assim, ambos eles podem ser feitos de uma forma prática fácil em formato de lista. Não deve ser um texto corrido. Você pode simplesmente fazer uma listinha do que você quer atingir e o que está fora do escopo. Minha dica para quando for definir esses objetivos eórum de escopo no caso dos objetivos é sempre bom a gente pegar algo metrificado porque como é que eu sei que eu atingi com a minha solução aquilo então é bom que a gente possa ter métrica daquilo e no fórum de escopo simplesmente não falar se o meu objetivo simplesmente eu nego o objetivo se o meu objetivo é ter maior resiliência, eu vou colocar no fora de escopo. Eu não necessariamente vou chegar no escopo e falar assim, não quebrar a aplicação. Isso não é um tipo de fora de escopo, tá? É um requisito. A ideia é que você coloque coisas que realmente não vão ser contempladas naquela solução que você está propondo. Seja sucinto, que nem eu disse, a ideia de fazer em lista é para que você coloque, mas ao mesmo tempo toma cuidado, tá? De ser sucinto, porém objetivo. E aí ao invés de você simplesmente falar, vai reduzir custos, o que não diz muita coisa, escreve assim, vai reduzir custos através da redução do tráfego. Então, seja um pouco mais sabitível e para a pessoa que vai ler, ela ter um melhor entendimento sobre aquilo. Vamos ver isso na prática, então. Esse aqui eu tive que separar em dois, porque eu tenho objetivos fora de escopo. Então, exemplos práticos de objetivos. É reduzir o tempo de resposta do sistema de vendas online, para melhorar a experiência do usuário. Então, eu tenho como metrificar essas duas formas, inclusive. Eu posso ver se a experiência do usuário, de alguma forma, melhorou, e eu posso, inclusive, colocar uma métrica lá para verificar o tempo de resposta. Melhorar a escalabilidade do sistema de vendas para atender a demanda crescente de usuários. Aumentar a taxa de conversão de vendas ou oferecer uma experiência do usuário mais rápida e intuitiva. Mais uma métrica, algo que eu posso ir lá, colocar uma métrica no código e ver se eu atingi o meu objetivo. E uma última coisa é facilitar a manutenção e evolução do sistema de vendas online. Isolando o código legado, que é aquela API legada, e fornecendo uma camada de ilustração para APIs. Nesse caso, a API do Back Engine é no sentido de uma API especificamente para o dispositivo móvel, onde eu posso ter campos específicos para aquele dispositivo. E aí, eu venho com o que é fora de escopo, o que eu não vou tratar. Então o que eu não vou tratar? Nesse documento eu estou resolvendo um problema que é o tamanho demasiadamente grande do payload. Eu não vou tratar aqui de criação de novas funcionalidades principais do sistema de venda. Eu não vou tratar também de uma implementação de segurança de alto nível no BFF, que será especificado em outro projeto. E eu também não vou criar um cache, está fora de escopo. Repare que poderia ser algo desse escopo, mas está fora, principalmente deste momento que eu estou escrevendo o documento, que é a criação de uma solução de cache, que não vai ser abordada e pode ser implementada posteriormente. Então, isso é estar para o escuta. De forma que beleza, eu estou fazendo isso, mas eu não vou fazer isso daqui. Deixar nítido o porquê sim, o que eu quero atingir com aquilo e o que eu não vou atingir com aquilo ou o que eu não vou implementar. Tá? Agora vem a parte, talvez, a mais crucial de todo design in-box. Esse comecinho, a gente só colocou o problema, a gente deu uma visão, colocou o problema, só recapitulando, a gente colocou o problema, visão geral, entrou nos objetivos, o que a gente quer atingir com aquilo? Agora a gente vai realmente chegar no ponto onde eu vou escrever a minha solução. É o design e essa daqui provavelmente vai ser uma parte mais longa na explicação, que é o seguinte, eu tenho dado o meu contexto, que são aqueles fatos que eu já coloquei, os objetivos que eu quero atingir, os não objetivos que eu tenho, que é aquilo que eu não vou contemplar. Mostre por que uma determinada solução atende melhor a esses objetivos. Então, é escrever uma solução, mostrar o porquê que ela vai atender aqueles objetivos. Começa por uma visão geral, tá? E aí nós não estamos falando daquela primeira visão geral, nós estamos falando de uma visão geral da solução e depois entra em detalhe. E aí quando a gente for entrar em detalhe, a visão geral é no sentido, ah, uma visão geral. A gente está comprovando de payload, a gente quer colocar um BFF, a solução de forma geral é colocar um BFF, mas como que esse BFF vai ser introduzido em todo o nosso sistema? Então, nessa parte, a gente pode e deve conter diagramas com contexto e as aplicações que eu tenho. Nesse caso, vocês vão ver que eu vou dar até um exemplo aqui. APIs que eu tenho. É sempre bom colocar qual é a API que eu estou afetando, o que eu estou mudando, o que eu estou planejando. E aqui eu deveria ter dado até um destaque. Dados. É que nesse caso, na verdade, eu não falei sobre dar dados, mas no sentido, que dados que eu estou manipulando? A partir do momento que eu estou distraindo a minha API para um BFS, eu contenho algum dado sensível ali? Tudo isso é importante nessa parte aqui. Eu posso ter códigos, mas isso é raro, pseudocódigos, porque às vezes eu estou escolhendo de um novo algoritmo que eu estou fazendo. Eu posso ter alguma tela para dar contexto. E payloads. Às vezes payloads que vão ser super pegados. Outros diagramas, como os de sequência, também podem ser úteis. Principalmente se eu tenho um caso de uso novo, um fluxo novo, ou coisa assim. E aí, dê foco nas compensações para produzir um documento útil com valor a longo prazo. Como que eu produzo um documento bom e que tenha valor? Eu sempre dou destaque, se eu fosse falar uma coisa, um ponto principal da minha solução, que eu devo dar maior destaque, é as compensações, os trade-offs. Por que aquela decisão foi tomada? E as soluções podem estar restritas a um sistema antigo ou biblioteca ou podem ocasionar soluções não ótimas e aí a gente pode ter aqueles projetos que são os greenfields, aqueles projetos que eu tenho toda a liberdade de escrever toda uma série de regras ou eu tenho projetos que estão limitados a algumas coisas legadas e aí, nesses casos de legado, não a gente fica naquela dúvida, não, mas é, eu tenho um legado. E aí, nesse caso, eu não tenho uma solução, às vezes, ótima. Quando eu não tenho uma solução ótima, é interessante que vocês foquem na melhor solução possível, considerando as compensações. Então, se uma palavra é muito importante nesse ponto, é compensação. Falar, prós e os contras daquela solução. Normalmente destacando o porquê aquilo foi decidido. Você tomou a decisão por escolher aquela ferramenta ou sistema, enfim, e aí você coloca todos os prós que levaram a isso. Utiliza dados e fatos. Isso é muito importante, não chega num documento e escreve vamos reduzir o payload. Não, coloca faz uns testes, faz uma pauta, escreve vou reduzir 30% do payload me traz números mais factíveis. Quando você vai falar em coisas que você vai manipular ou coisas que vão ser acessáveis, usa dados. Hoje a gente quer reduzir o número de chamadas que a gente precisa atender de forma manual e a gente vai criar uma determinada automação. Beleza, o que é um dado para isso? Hoje temos 10 mil chamadas. Coloque esses dados no documento. Temos 10 mil chamadas. Queremos reduzir para zero. Então traga fatos e dados para dar valor nesse documento. Não copie e cola todo um esquema. Não coloca lá todo o seu modelo R, toda a sua API. Não, não faz isso. Quando eu digo para colocar payloads ou API, é muito especificamente para mostrar um determinado problema que você está resolvendo. Se você acha que aquilo vai tornar muito poluído o documento, não traga. E elementos visuais são complementares, e não substitutos de explicação. Isso aqui está no sentido de, coloque um diagrama, mas explica a sua solução. Não simplesmente coloque um diagrama e espera que as pessoas vão ler e entender. Por melhor que esteja o diagrama, e olha que existem alguns diagramas de quatro que você vai e lê e não consegue entender tudo aquilo, mas sempre tem detalhes que normalmente quando são explicados você acaba perdendo mais. E aí, um exemplo prático, eu não vou ler ele todo, porque é grande, mas é, o objetivo desse projeto é melhorar a experiência do usuário, a sua habilidade e o sistema de venda. Adicionando o BFF para fornecer recursos mais leves e uma experiência mais fluida. E aí ele fala sobre o uso de Tomcat, BFF, Spring Boot, uma camada de API. Repara que agora eu estou entrando em detalhes. Se antes, até essa sessão, eu não estava falando nada detalhado, nesse ponto eu não entendi o detalhe tudo. Quando eu falo, aqui está a minha detalhe, aqui eu estou detalhando tudo. Eu falo sobre aumento da conversão de vendas e etc. Eu trago os prós e os contras dessa minha solução. Ah, vai ter uma melhoria na experiência do usuário. Eu consigo criar API específica para cada... Se eu tiver, de repente, uma outra aplicação, que não seja dispositivo móvel ou qualquer outra coisa, eu posso ter um payload próprio para ela. Porque ele está desocoplado da API, eu não preciso de alteração na API. Eu tenho uma redução de 30% no payload, então repara que eu trouxe dados, entendeu? E repara que eu trouxe alguns contras, que é, eu tenho uma maior complexidade, eu preciso implementar isso, eu vou introduzir um componente novo, eu tenho um aumento de tempo e custo de desenvolvimento, mas, por mim, tudo bem, são custos, são aquelas compensações que eu estou disposto a pagar. E assim, eu tenho a necessidade, aqui tem mais uma, que é a necessidade de garantir que as API's estejam bem projetadas para suportar uma organização BFF. Mas assim, são coisas que, por exemplo, eu tenho, mas eu pago esse preço, porque os prós são mai