Bom pessoal, agora a gente está começando esse capítulo aqui sobre algumas decisões arquiteturais. Na minha opinião, esse capítulo é um dos mais importantes, inclusive, desse módulo de arquitetura. Por quê? Porque ele vai resolver e vai pegar na veia um problema que eu não tenho dúvidas que você já passou e se bobear você já está passando, que são como tomar algumas decisões arquiteturais. E o momento que você tem que tomar essas decisões. Legal? Então, vamos entender um pouco mais sobre isso aqui, galera. Nós, normalmente, tomamos decisões muito erradas na hora de a gente iniciar o desenvolvimento de um software. Como assim? de um software como assim normalmente apesar disso parecer que está acabado né a gente acaba indiretamente sofrendo um pouco ainda com aquele efeito do waterfall o que significa muita especificação sem geração de código não estou dizendo que você não tem que ter especificação mas quando você começa a documentar tanto tanto tanto dá muitos passos pra frente antes mesmo de ter algo funcionando na sua aplicação provavelmente essa é uma decisão completamente, eu digo, errada, na minha opinião, tá? Eu não tenho que dizer que a sua aplicação não tem que ter um desenho, ela não tem que ter uma arquitetura, ela não tem que ter uma especificação. Mas se você voltar lá 20, 30 anos atrás, como as pessoas trabalhavam com essa metodologia antes de a gente falar de Agile ou qualquer coisa desse tipo, era isso que prendia o software fazia o software ser descolado da realidade você estava lá arquitetando coisa lá na ponta e o software não tinha nem tomado a forma ainda e daí de repente, no final das contas o que aconteceu? o cliente nem viu nada funcionar o software nem gerou nenhum valor pra ele. Quando você botou no ar, essa especificação mudou e toda a documentação tem que ser refeita daquele jeito. Então, a gente ainda sofre, ainda tem empresas sofrendo com esse tipo de coisa, tá? Quando que isso normalmente acontece, principalmente quando a gente tá falando em arquitetura ou com arquitetos e arquitetas de software. Isso acontece principalmente quando os caras estão iniciando nessa atividade. Por quê? Porque agora ele é um arquiteto. E o que que um arquiteto faz? Ele documenta, ele pensa, ele acaba criando regras, ele ajuda a especificar muita coisa. E daí o cara fala, agora eu sou arquiteto, deixa eu especificar. Agora eu vou fazer aquele negócio decente. E daí o que acontece? Você viu que o cara criou 300 páginas de especificação, como é que vai funcionar a aplicação. Pegou o TOGAF de ponta a ponta para conseguir implementar e eu não estou dizendo que togaf ruim tá mas o que acontece no final dessas coisas não gerou o valor para a equipe a então vamos pensar aí que se você está começando nesse meio de arquitetura e você começa a se pegar cada vez mais se perdendo em documentações pensando muito mais pra frente o que está acontecendo na sua aplicação no momento toma cuidado porque é um sinal de alerta muito forte pra você não está sofrendo os resquícios aí da da modalidade waterfall que normalmente a gente tinha ali há 30 anos atrás. Então, vamos tomar muito cuidado com isso aí. Próximo vídeo, a gente vai falar sobre um outro cuidado extremamente importante que a gente tem que tomar. Vamos nessa!