E aí eu trouxe exemplos visuais. Esse aqui é o mesmo sistema que a gente está falando. É um comprador, ele agora vai ter um dispositivo móvel que é novo, que vai bater no BFF, BFF consulta API. Esse aqui é o modelo C4. Eu poderia fazer só uma apresentação inteira sobre C4, mas quem quiser, o próprio canal do Wesley tem uma apresentação minha sobre esse modelo de documentação de arquitetura de software que, particularmente, eu gosto bastante e tenho usado em todos os lugares que eu passo. Uma outra coisa que pode enriquecer aqui, não necessariamente vai enriquecer, mas pode, é trazer, às vezes, um fluxo. Repare que aqui eu tenho um fluxo. Diferente daqui, que eu tenho um diagrama um pouco mais estático, eu simplesmente falo quais são os meus componentes e como eles interagem, aqui eu tenho uma coisa um pouco mais específica que é, eu tenho o fluxo da minha requisição que vai para o aplicativo móvel, que vai para o BFF, que vai para a API, e esse retorno da minha resposta já alterada para ter uma experiência um pouco mais segura no aplicativo móvel. Então assim, não é que tem que ter tudo isso, tá? Eu estou mostrando o exemplo de como você pode enriquecer um documento. E aí, vocês viram que a gente já chegou na nossa solução. Só que, além da solução, a gente tem mais algumas coisinhas para colocar. Uma delas são, beleza, você só considerou aquilo, tipo, eu só considerei botar um BSTF ponto, normalmente quando a gente começa uma discussão, outras pessoas vão opinar. É sempre bom anotar, porque a gente pode incluir isso como uma sessão de time-dose. E aí, os sistemas ou soluções alternativas que foram considerados para a resolução do problema e tiveram alguma compensação e motivação para que eu não escolhesse, eles vão contar aqui na minha alternativa. E aí a ideia é essa. Eu vou dar uma dica dessa parte, que é o quê? Uma alternativa sempre é não fazer nada. É tipo, ah, beleza, eu não vou fazer nada, vou plugar meu aplicativo e vou me limpar. Por que eu não vou fazer isso? Outra, ah, eu tenho um problema hoje de escalabilidade, como que eu resolvo? E aí até eu dou um toque, o que eu me esqueço, lá no design, quanto maior a empresa, vocês vão ver que eles envolvem algumas coisas como SLO, SLA, SLI, que são, tipo assim, qual o objetivo que você quer, qual o indicador daquele objetivo e qual é a disponibilidade. Então, assim, normalmente isso vai em aplicações maiores e tudo mais, mas é uma coisa legal se você tem uma noção. Por exemplo, eu estou esperando, lembra quando eu falo de dados, trazer números? Se você tem uma noção de usuário dia, esse tipo de coisa, coloca lá. Documento, ele enriquece muito quando ele tem número. E assim, passando por uma experiência que eu já tive, normalmente quando você leva para as pessoas mais simples, eles vão te cobrar, eles vão te perguntar no sentido, não, beleza, você está falando que isso aqui vai crescer, o problema é que isso aqui vai crescer, mas quanto vai crescer? Se crescer 1%, esse crescimento não é nada para mim. Enfim, mas voltando para as alternativas, a ideia é, uma alternativa não fazer nada, deixa o jeito que está, mas por que eu não vou deixar o jeito que está? E é bom explicar isso, o foco tem que estar na compreensão sólida, que cada design levou ao tópico principal. Se o meu documento dá uma solução A, se eu colocar uma solução alternativa B, eu vou explicar por que B não foi escolhida em detrimento da A. E aí, seja isso simples, mas destaque por que a solução escolhida é a melhor. Por que você escolheu a outra e não a que você tem? E aí a gente tem, por exemplo, do nosso sistema que a gente está desenvolvendo que a gente está colocando aqui, eu poderia fazer a mudança do payload através da cabeçada do HTTP. Por que eu não decidi fazer isso? Porque a implementação e manipulabilidade vai ser prejudicada para futuras alterações. Eu vou ter mexido em código, enfim. Aqui o exemplo pode parecer meio estranho, mas é só porque eu quis trazer só esses pontos. E a outra coisa é, beleza, eu poderia ter feito uma compressão de dados. Beleza, agora eu respondo GVIP e resolvo. Mas aí eu coloquei essa solução. Lembra sempre da compensação. Essa solução não foi adotada porque não é eficaz. A redução foi de 10% do payload. E uma outra coisa é preocupação transversal, que eu citei lá no começo, que é descrever o que pode impactar outras pessoas. Pode ser uma preocupação transversal, que eu citei lá no começo, que é descrever o que pode impactar outras pessoas. Pode ser uma preocupação de segurança, às vezes tem um campo ou coisa confidencial, uma quebra de compatibilidade da API. Se eu mudo a minha API, como que eu vou impactar outras pessoas? Um aumento de fluxo em outros sistemas, porque agora eu vou ter um fluxo novo, vou começar a mandar tráfego para um outro sistema. E essas pessoas desse sistema estão sabendo que eu estou mandando as coisas para lá? Enfim, e coisas relacionadas à infra, hoje a minha organização, ela dá suporte a uma determinada tecnologia, eu quero botar uma quantidade de grafos, isso é uma preocupação transversal, sabe, e não só isso, se eu impacto ou tenho times que estão envolvidos em numa solução, eles também vão entrar aqui. Ah, o time tal, ele está trabalhando em conjunto porque a gente está trabalhando numa solução que precisa mexer aqui, mexer lá e mexer num outro. E o mesmo vale para pessoas que estão impactadas. Porque às vezes eu mudo a minha API e impacto alguém. A minha dica para isso é, envolve o time o mais cedo possível. Escreva o documento na hora que tem uma primeira discussão, já leva o documento e já leva para a pessoa. Já leva o primeiro documento, o primeiro rascunho e já inclui aquelas pessoas, os outros times que podem ser envolvidos no encastado. E peça revisão para essas pessoas. Entrega o documento e fala, revisa para mim, a gente precisa de um apoio nisso. E aí eu botei um exemplo que é É importante para o nosso BFF que ele seja projetado e implementado de forma segura, com o seu pacote de criptografia e autenticação. Então, ou seja, eu estou incluindo as minhas preocupações de segurança e é necessário a compatibilidade da API com o BFF para que não haja problemas de integração. Ou seja, quem estiver desenvolvendo a API, não necessariamente sou eu, eu tenho que me preocupar com isso. E é importante monitorar o aumento de dificuldade que isso pode gerar. Então, é só uma preocupação se eu tenho. Eu coloquei isso aqui só de exemplo mesmo, para ter uma noção de como esse documento é escrito. E aí, por fim, para não ficar extremamente extensa, eu sei que esse meio já está muito extensa, eu separei aqui só com algumas últimas coisas que são testabilidade e observabilidade. Como que eu vou testar aquilo? Vai ter teste unitário, vai ter teste de integração, mas não só isso. Quando aquilo for colocar em produção, quais as métricas que eu tenho para atingir o sucesso e não só isso, como que a solução vai ser observada? Quando eu colocar isso em produção, o que eu vou ver? A gente vai ter um plano de implantação. Beleza, não necessariamente eu vou fazer essa mudança abrupta. Eu posso, de repente, desviar 10% do tráfego para a minha nova aplicação. Vamos supor que eu estou trocando uma aplicação. Eu posso ter 10%, depois 20%. Isso vai ser faseado. É literalmente como a gente vai fazer o nosso plano de roll out. Como que isso vai ser colocado, às vezes é uma novidade, eu quero fazer alguns fecha-b, ou coisa assim. Então, esse plano de como é que isso vai ser feito. E o mais legal é perguntas em aberto. Nem sempre a gente tem resposta para tudo. E às vezes a gente não sabe. Às vezes alguém vai levantar uma questão e a gente não vai saber responder