Bom, meu povo, e agora vamos para o nosso último tópico aqui do nosso módulo sobre arquitetura de solução. E esse tópico aqui é um pouco controverso, porque a gente vai falar sobre SAD, que é o Solution Architecture Document. que é o Solution Architecture Document. Basicamente, esse cara aqui é o que vai nortear o trabalho final do arquiteto de solução. O grande ponto aqui que a gente tem que levar em conta é o seguinte. Esse documento vai ser maior ou menor, mais específico ou menos específico mais específico em algumas partes e mais generalista em outras partes de acordo com o projeto e normalmente como eu sempre digo quanto maior o risco em determinadas partes mais detalhes a gente tem que ter? Isso aqui, galera, que a gente está falando, ela não apenas contém dados técnicos, mas são dados que vão ajudar, inclusive, gestores e diversos tipos de stakeholders a entenderem melhor aquilo que vai ser implementado. E o mais importante de tudo tá isso aí galera é algo que ninguém acaba levando em conta só leva em conta quando você está no campo de batalha que é o seguinte o arquiteto de solução ele é o braço direito do cara do comercial é ele é o cara que vai ter contato direto com um cliente final por exemplo uma consultoria e o documento que ele gera no final das contas vai ser uma prova sobre o que está sendo combinado em relação ao produto final tá e novamente normalmente como dizem pau que bate em chico bate bate em Francisco. O que significa? Se esse documento for muito bem feito, e acontecer qualquer coisa que não estava previsto no projeto, esse documento é a prova disso. E essa prova pode ajudar, pode suportar a opinião da empresa em relação ao cliente, sei lá, podendo cobrar mais por funcionalidades que não estavam ali no escopo, como também podem advogar contra a empresa porque ela não está entregando aquilo que tinha sido combinado. Por isso que o risco é algo que tem que levar muito em conta na hora que a gente gera esses documentos porque ele tem que realmente especificar deixar de forma extremamente transparente o que vai ser entregue obviamente que conforme esses documentos eles vão ficando mais específicos mais técnicos eles vão se tornando porém isso não importa porque porque a idéia geral desse documento é conseguir atender uma gama de stakeholders desde um gestor de um diretor até mesmo o cara técnico sei lá de uma outra empresa de uma outra consultoria ou até mesmo da empresa que vai a trabalhar dentro do projeto tá então esse documento de solução arquitetura documento ele é bem importante o que a gente vai fazer nesse capítulo no final das contas eu quero passar pra você tá os principais tópicos que esse documento compõe. Obviamente, a gente não vai digitar, a gente não vai criar um documento desse do zero. E o porquê que eu estou dizendo isso? Porque a gente precisa ter um projeto em mente, a gente precisa ter escopo, a gente precisa ter contexto. E esse documento, normalmente, ele é muito grande. precisa ter contexto e esse documento normalmente é muito grande por outro lado tá existem diversos templates que vão te ajudar a não partir do zero na hora de você criar um documento eu vou deixar alguns links ali pra você legal lembrando também tá que esse módulo é um módulo de fundamento sobre arquitetura de solução a gente tem um módulo tá que ele é focado em sistema design tá e design docs esse módulo ele vai nos ajudar vamos dizer assim a complementar por exemplo gráficos diagramas e pontos específicos que normalmente inclui num solution arquitecture document mas também ao mesmo tempo ele também vai nos ajudar a criar padrões a documentos que vão ser muito importantes para deixar cada vez mais transparente a relação com os desenvolvedores que as empresas com todos os stakeholders beleza então vamos falar sobre essa id e vamos nessa galera