Bom, pessoal, agora que a gente falou um pouco mais sobre arquitetura versus design, eu quero falar algo bem interessante aqui para vocês, que vem do livro de Software Architecture in Practice. E ele fala algo que realmente é muito importante para você entender. Toda vez que você está falando de arquitetura Você está falando de abstração E olha só que interessante o que ele fala aqui Ele fala que a arquitetura, de forma geral, é uma abstração De um sistema que normalmente seleciona alguns detalhes E esconde outros detalhes Em todos os sistemas modernos os elementos eles vão se interagir né é entre outros através de algumas interfaces partições e tudo mais né alguns desses elementos eles vão interagir porque esse elemento são públicos alguns outros elementos eles são privados normalmente a arquitetura ela está mais preocupada com o que com os elementos que são públicos tá os elementos privados normalmente eles falcam muito mais numa implementação interna e não necessariamente arquitetural olha só só que fantástico, tá? Olha só, ele acabou caindo de forma geral um pouco mais naquela parte de design e também a arquitetura. Mas olha só que interessante, toda vez que eu estou criando uma arquitetura de um software, eu estou pensando em abstrações, eu estou pensando de uma forma geral de como que um problema é resolvido. Porém, todo problema que eu vou resolver tem dois lados. Um lado é o lado que todo mundo consegue ver. É o lado que todo mundo se conecta com ele. É um lado que todo mundo depende dele. Por outro lado, esse sistema, para ele ter esse lado público, ele também precisa ter lados privados. Esse lado privado dos sistemas não são tão importantes em relação à abstração de arquitetura. São decisões de design importantes que você tem que ter no seu software mas a parte arquitetural não está tão preocupada com essa parte privada ela está muito mais preocupada com a parte pública legal olha só que interessante vamos imaginar que a gente vai desenvolver uma API REST. Quem está consumindo essa API, ela tem que ter, vamos pensar, uma documentação, ela tem que entender como que a API vai funcionar, os elementos, a forma de retorno, como que tudo isso vai trabalhar. Isso aí tende a ter diversas decisões arquiteturais. O payload que você tem que mandar, como que você vai dar as responses, os códigos de erros de como que você vai trabalhar, muitos sistemas vão se conectar ali. Mas esses sistemas, eles estão preocupados com essa parte. Ele não está preocupado com o que está gerando aquilo. Para eles, isso aí é uma caixa preta. Então, as decisões arquiteturais estão muito mais focadas nessa parte pública do que necessariamente na privada. As partes privadas é ponto de resolução de quem está desenvolvendo e não faz sentido isso ser exposto necessariamente para quem está consumindo. E quando eu estou falando isso, eu não estou falando isso apenas em APIs ou servers que você vai trazer. Eu estou dizendo, inclusive, isso entre componentes dentro do mesmo sistema. Eu vou dar um exemplo mais claro possível aqui, uma coisa muito boba. Eu tenho alguns métodos públicos e eu tenho métodos privados. Pensa bem, os métodos públicos podem ser utilizados por outros pacotes dentro da sua aplicação, com áreas diferentes, áreas que são segregadas, inclusive. Imagina, eu estou desenvolvendo o meu monolito modular, mas eu que estou chamando diversos componentes, eu não estou interessado em como aquilo se comporta internamente, porque normalmente isso são feitos através dos nossos métodos e atributos privados, eles são escondidos. Normalmente as decisões que a gente pensa em arquitetura são naquele momento onde os componentes vão se falar, de interfaces essas interfaces elas podem ser aquela interface de orientação objeto mas podem ser interfaces de protocolos que vão ser chamados de rpc um resto um gráfico é o etc então perceba novamente toda vez que você fala de arquitetura você pensa em uma abstração