| path | title | subtitle | date | tags | banner | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
/arquitetura-alem-da-estrutura-de-pastas |
Arquitetura além da estrutura de pastas |
Uma estrutura definida e uma boa organização podem passar impressões diferentes do que uma arquitetura realmente significa |
2021-09-23 |
|
|
Quando vemos conversas sobre arquitetura, alguns aspectos sobre a forma como uma aplicação é construída, mantida, organizada e definida em seus componentes internos e externos são importantes.
Esses aspectos são essenciais pra entender a arquitetura de um software, e é justamente por tocar tantos tópicos diferentes que não é uma coisa simples de ser traduzida. Não é a toa que existem tantas documentações, livros, posts (como esse) e vídeos sobre o assunto.
Se pararmos pra pesquisar o próprio significado de arquitetura, temos algo como:
"Arte de projetar e construir edifícios"
Fonte: Priberam
Estou longe de trabalhar na área de construção civil, mas tenho certeza que o trabalho, a quantidade de profissionais, a gama de conhecimento e instrução necessária pra criar um prédio, com certeza vai muito além de apenas uma boa organização e manter seu local de trabalho (como suas pastas) bem organizado.
Uma boa organização e divisão de pastas é uma estrutura e não uma arquitetura. Vale inclusive lembrar que ela pode ser traduzida em uma estrutura de dados específica (como árvore, igual já comentamos aqui).
Por si só, uma organização de pastas não define limites e camadas da sua aplicação ou domínios de negócio de um projeto.
Toda vez que eu ouço comentários como "você faz essa pasta X e essa Y e a sua arquitetura fica bem melhor" eu me faço uma mesma pergunta.
Na verdade são duas, mas logo com a primeira já dá pra ter uma ideia do que eu quero dizer. E elas são:
- Se estrutura de pastas definisse arquitetura, todo monolito deveria ser composto por somente uma pasta (ou um arquivo)?
- Será que micro-serviços (ou micro-frontend) é somente um monte de pastas (ou arquivos) separadas então?
O que eu mais gosto nessas questões é que elas realmente colocam os dois assuntos e o entendimento sobre eles (que podem se entrelaçar) em conflito e ajuda bastante a entender sobre as diferenças e é com essa resposta que a relação (ou a falta dela) entre as duas coisas ficam mais claras.
Independente se você já trabalhou com monolito ou micro-qualquer-coisa, você muito provavelmente respondeu não para as duas perguntas e isso aconteceu justamente pelo conflito que esses aspectos arquiteturais causam quando a gente pensa neles como se fossem somente estruturas de organização. Viu como uma estrutura não necessariamente tem relação com a arquitetura?
Quando falamos de divisão de responsabilidade, monolito e micro-qualquer-coisa estamos tocando em alguns aspectos arquiteturais que podem ou não estar relacionados com uma organização de pastas.
Bom... Se não é somente uma estrutura de pastas, o que é então?
Abaixo listei alguns tópicos que podem ser considerados e fazer parte de uma arquitetura.
Isso não quer dizer que arquitetura é única e simplesmente isso ou somente esses pontos que anotei. Muito pelo contrário, a ideia aqui é dar um pequeno "cheiro" de como esse tópico pode ser compreendido em diversas perspectivas diferentes.
Ao longo desses tópicos você vai encontrar algumas perguntas que eu mesmo me faço quando preciso explicar uma "arquitetura" em alguma conversa.
Podemos entender como "camada", na maioria dos cenários, os diversos componentes com diferentes responsabilidades numa aplicação e isso influência a forma como a arquitetura de uma aplicação é feita.
Se pensarmos em uma aplicação front-end, podemos pensar nos componentes de interface mesmo e como eles interagem entre si ou com seus estados e requisições.
Se pensarmos em uma aplicação back-end podemos pensar nos módulos e pacotes responsáveis por diferentes operações como serialização de um JSON quando uma requisição é feita, formatação de alguma resposta ou salvar algum dado no banco.
Aqui podemos pensar ainda em diversos componentes: internos e externos ao projeto, sejam dependências ou não.
Sobre as camadas que acabamos de comentar, um outro aspecto importante pra arquitetura é como os dados fluem entre essas mesmas camadas.
Como funciona o fluxo de entrada e saída? As informações são salvas ou processadas por alguma tarefa em segundo plano? Salva em algum banco? Ficam armazenadas em um estado global?
A forma como os dados são tratados e trafegados entre essas diversas camadas também importante pra uma arquitetura.
A forma como uma aplicação é disponibilizada pra quem vai utilizá-la também é parte da arquitetura.
Essa aplicação é uma API em REST? Ou é uma aplicação front-end disponibilizada pra ser consumida via navegador? É uma biblioteca que pode ser baixada como uma dependência e carregada em um projeto?
Caso seja uma aplicação front-end, ela segue algum padrão de renderização no servidor, é servida com apenas arquivos estáticos ou segue um modelo de SPA? Já comentamos aqui sobre algumas diferenças entre esses "tipos de renderização" e isso também está ligado com a arquitetura do seu sistema.
Caso seja uma API em REST, quais endpoints sua aplicação irá disponibilizar pra que sejam consumidos? Quais os dados você espera? Quais respostas irá fornecer quando os endpoints forem chamados?
Caso seja uma biblioteca que pode ser adicionada em um projeto, os métodos e a forma como esse mesmo projeto vai interagir com essa dependência através de processos e chamadas de funções faz parte da arquitetura dessa aplicação.
Aqui poderíamos até nos aprofundar um pouco em algumas questões que tocam infraestrutura como a quantidade de máquinas ou serviços em nuvem necessárias pra servir uma aplicação ou qual estratégia de cache para arquivos estáticos está sendo usada.
Esse tópico já entra um pouco mais em alguns detalhes de implementação na grande maioria das vezes, mas alguns padrões acabam influenciando a arquitetura de uma aplicação também.
Por exemplo: uma cadeia de middlewares (que segue o padrão de "cadeia de responsabilidade") pode ser aplicado de diversas maneiras.
Alguns frameworks como Express aplicam esse padrão com uma implementação, você poderia aplicar de outras formas (até com um loop mais simples), mas a lógica por trás da estrutura, é a mesma e isso acaba definindo as regras que ditam como sua aplicação deve crescer à longo prazo.
Essa seção foi fortemente influenciada por essa thread no Twitter com o William Santos (@wsantosdev) e o principal ponto que eu queria ressaltar aqui é que, como ele mesmo comentou, a linha entre design e arquitetura de software é muito turva.
Foi um papo muito enriquecedor onde trocamos ideia sobre decisões arquiteturais estarem mais relacionadas com impactos no negócio, e todas as outras serem mais voltadas à decisões puramente de implementação do projeto mesmo (como um padrão MVC, por exemplo).
Além disso, queria trazer outra fonte bacana aqui que ele recomendo de conteúdo (que deve se tornar um livro) chamada Manual do Arquiteto de Software em criação pelo Elemar (@elemarjr).
Esses foram só alguns tópicos que me vieram à cabeça sobre arquitetura em geral, mas isso não quer dizer que somente isso seja uma ótima definição sobre o assunto. A ideia era principalmente abordar outros pontos que às vezes podem ficar de lado em conversas técnicas quando falamos de um sistema com um pensamento mais "alto nível" e sem entrar em detalhes específicos de código e implementação.
Por tudo isso que comentei, é importante não confundir uma estrutura com uma arquitetura. Uma organização e estrutura de pastas pode fazer parte de um projeto e contribuir de forma positiva (ou não) pra sua arquitetura, mas não é essa estrutura que define a arquitetura de um sistema.