Cara, algumas perguntas aí para você. Eu acho que desde a parte de contexto, a parte de cabeçalho, esses tipos de coisas, eu acho que ficou bem interessante. No principal ponto é, tem que ser simples. Tem que ser simples. Se o negócio não for simples, ninguém faz. Essa é a verdade. E você não tem que ser um autor de livro para ter que ser capaz de conseguir escrever um design doc. Agora, o grande ponto aqui que eu queria te perguntar, Cássio, é o quão detalhado esse meio do documento precisa ser. Porque hoje em dia, se a gente olhar nos conjuntos de documento, a gente tem ADRs, Architecture Decision Records, a gente tem SADs, Solution Architecture Documents, a gente tem RFCs e etc. Muitos desses documentos são extremamente técnicos, eventualmente uma RFC, e etc. Muitos desses documentos são extremamente técnicos, eventualmente uma RFC, por exemplo. Qual é a diferença do design doc em si com esses documentos que muitas vezes são amplos para caramba? O design doc, primeiro colocando, só para trazer uma visibilidade de tamanho. Qual é o tamanho que deve ser o design doc? Eu acho que isso ajuda na resposta dessa pergunta. Depende da complexidade que você estiver resolvendo. E aí, eu trago por exemplo o prático. Normalmente esses design docs, se não perder uma, três páginas, pode ser algo simples como uma única página, ou pode ser um pouco mais complexo a três páginas. Pode ser algo simples, como uma única página, ou pode ser um pouco mais complexo, como três páginas que se escreve. Eu já vi que o endócrino é maior que três páginas. E não é porque a solução, às vezes, é muito complexa. E, às vezes, você tem de detalhar um monte de coisa. Ou, às vezes, aquela solução impacta e traz as compensações, elas envolvem de muitos fatores. Mas o mais habitual, o mais comum, é de uma a três páginas. Não passa mais que isso. Estou falando de experiência de várias empresas e de o que eu tenho visto e até conversado. E o que eu tenho visto nos posts de outras empresas também, eu conversado com outras pessoas. Costuma ficar assim. de outras empresas também ou conversar com outras pessoas. Costuma ficar assim. Aí fazendo um comparativo com ADR, SAD, na verdade todos eles tem muita similaridade entre si. O RFC tem essa coisa do muito técnico, ele normalmente é uma implementação que é bem, é mais formal, tem uma estrutura um pouco mais engessada. Mas eu até trouxe, daqui a pouco eu vou colocar ali, o Elton Mineto, na Praia eles usavam RFC, e aí tem um modelo de RFC um pouco menos pesado nesse critério de trazer essa formalidade. Então, é um pouco difícil de falar dos outros documentos porque cada um tem suas especificidades, suas particularidades. Ele pode ficar tão grande quanto pode ser pequeno. É uma pergunta que fica bem, depende. Normalmente ele vai crescer de acordo com a solução. Se tem um problema bem difícil de resolver, provavelmente a solução vai ter que ser um pouco mais detalhada. Show de bola. E em qual momento esses documentos entram, Cássio? Por exemplo, eu tenho SAD, eu tenho RFC, eu tenho ADR, eu tenho o design doc em si. Em quais momentos esses caras entram? Por exemplo, um ADR pode estar dentro de um design doc? Ele pode ser considerado um design doc? Como é que... Onde que está essa linha em relação a esses documentos todos, cara? É uma linha muito tênue, na verdade. Hoje mesmo eu estava lendo um post sobre a pessoa cita sobre RFCs like e ele coloca o DynDoc como um RFC like. E, ok. Sabe, porque não deixa de ser. Eles tratam de decisões o próprio ADR é uma decisão é uma decisão, é um registro daquilo que você fez. Normal normalmente ele tem uma estrutura ali, ele pode ser grande ou pode ser pequeno, mas se você parar para olhar, ele tem campos bem próximos do que eu tenho como Design Doc. Só que o Design Doc, um ponto onde sai um pouco desses outros documentos é que o design doc ele tem uma coisa do design o ADR é mais, eu vou documentar sabe, uma decisão arquitetural, o design doc ele vai muito mais no sentido não a decisão, mas o design em si a história de tudo como isso está também, O ADR fala, olha, as decisões que foram tomadas para esse projeto são essas, essas, essas, por conta disso, disso, disso, e está aqui. Quem alguém perceber, consegue saber quais são as nossas decisões arquiteturais. Agora, o design doc, ele tem muito contexto também. É que nem eu falei, Você pode escrever um design doc que ele tenha a decisão do porquê um banco é racional ou não é racional. Só que o ADR, normalmente, ele é mais direto. Ele vai ter essa decisão. É uma decisão arquitetural. A arquitetura definimos que é o banco. No caso do design doc, ele já seria um pouco mais amplo. Porque ele teria o problema com o qual a gente foi instruído. Toda aquela, sabe? Ele tem toda essa história. Então, assim, é exatamente isso que você falou. Ele contém um pouco mais de design. E aí, não só a decisão em si. E aí, você para pra olhar, normalmente, o que tá ali, na parte do design mesmo, e alguns pontos, não necessariamente todos é o que você tem em um ADR show de bola eu acho que aos poucos vai ficando mais claro porque tem muita gente que está acostumada a falar em RFC depois está falando em ADR o RFC ele tem como característica por exemplo comentários o nome é pedido por comentários pedido de comentários O RFC tem como característica, por exemplo, comentários. O nome é pedido por comentário, pedido de comentário. Mas vocês vão ver que no próprio ciclo de vida do design doc, ele tem isso, pedidos por comentário. Que vão ser as revisões. Então, assim, é por isso que eu falo que a linha é bem termina. Eu poderia dizer que, por exemplo, ADR é um documento que eu especifico quais foram as decisões arquiteturais que eu estou criando no meu sistema, falando como essas decisões estão sendo implementadas. Eu poderia dizer que uma RFC, no final das contas, é um Request for Comments, mas é um documento extremamente específico sobre uma determinada implementação, uma determinada solução que coloca os pingos nos is sobre tudo que vai acontecer de uma forma mais enfática para que outras pessoas vão trabalhando em cima disso até chegar numa decisão mais fina. Então, uma RFC não tem uma visão tão de alto nível. A gente pode dizer que muitas vezes uma RFC tem uma decisão muito de baixo nível de forma geral também. E quando a gente está falando de design doc, ele foca mais em alto nível, mas trazendo coisas no contexto da empresa de forma geral. Falei muita besteira? Não, na verdade não. Assim, tem considerações além disso. Você falou isso totalmente correto, mas aí tem aquele ponto onde você pode colocar RFCs e design docs bem similares. Não necessariamente você... Porque... Da maneira como foi colocada, pode, talvez, a pessoa entender de separação, segregação e coisas totalmente distintas. Não são. Na verdade, eles são bem próximos. Por isso eu digo que tem uma linha bem interna. Inclusive, por isso, dentro de um design doc, você poderia colocar, olha, a gente está fazendo esse backend para frontend, etc. A linguagem a gente acredita que faz isso, que vai resolver esse tipo de problema e, baseado nisso, a gente está fazendo uma RFC para especificar esses detalhes de implementação. Pum, vai para uma RFC que tem os detalhes mais finos de tudo isso. Poderia ter isso também, né? Acho muito válido. Perfeito. Tá bom então, Cassio. Vamos continuar que agora tem... Gente, não se preocupa para quem já está um pouquinho cansado. Agora a gente está indo para uma reta final aí, onde eu quero mostrar as ferramentas e mostrar uns feijões legais. Eu acho que eu vou responder algumas perguntas que eu já vi que tem no chat. Então vamos lá.