O conceito de arquitetura pode ter várias definições e níveis de abordagem em diferentes áreas de trabalho. Uma das abordagens mais comuns ao falarmos de arquitetura de software traz uma ideia geral de definir e reconhecer componentes de software, com suas propriedades e relacionamentos. Neste post, irei descrever as minhas respostas para as perguntas que costumo fazer em entrevistas referente ao tema “Arquitetura”, mencionado no post #0 da série.

Motivação

Entender o conhecimento do candidato em um nível mais macro de definição de soluções técnicas, saindo um pouco do nível de design de código e falando mais sobre o uso de diferentes tecnologias para resolver problemas e criação de sistemas complexos a partir de componentes de software.

Perguntas

• Qual é a diferença entre arquitetura de microsserviços e monolítica?

Resposta: A arquitetura monolítica não necessariamente é orientada a serviços e pode ser considerada um bloco único de componentes de software dependentes entre si e vinculados em nível de hardware, podendo ser distribuido em várias instâncias completas, mas com todos os seus componentes em cada infraestrutura. A arquitetura de microsserviços se baseia na arquitetura orientada a serviços e restringe um pouco mais o seu uso, definindo a ideia de contemplar escopos de entrega de valor menores, acoplamento a nível de serviço e independência entre si a nível de hardware, isolando a infraestrutura necessária para atender a cada microsserviço, ou seja, cada microsserviço deve ser independente a nível de negócio e infraestrutura, agregando valor de negócio isoladamente.

• Como você estruturaria um novo sistema em termos de arquitetura?

Resposta: Eu entendo que cada tecnologia resolve problemas diferentes e se propõe a ser especialista em algo, então isso pode variar muito de acordo com cada problema a ser resolvido. Se eu fosse pensar em zona de conforto para criar um sistema hoje, sem fazer uma pesquisa prévia de outras tecnologias, consideraria usar SOA com APIs RESTful em Java com Spring Boot, começando com uma arquitetura monolítica separada por módulos em uma infraestrutura Cloud, provavelmente usando AWS, banco de dados relacional PostgreSQL e/ou não relacional MongoDB, Elasticsearch e Kibana para observabilidade, para o back-end. No front-end trabalharia com Vue.js ou Angular e, se fosse para um cenário mobile, começaria por PWA ou WebView em Ionic antes de tomar a decisão de usar nativo em Kotlin para Android ou Swift para IOS, também pesquisaria mais sobre Flutter como uma alternativa. Para versionamento usaria git, podendo ser através do Gitlab e aproveitar a parte de CI/CD de lá, ou usaria o Bitbucket e Jenkins.

• O que é um sistema legado?

Resposta: Vejo que o que construo hoje, hoje mais tarde já virou legado. As tecnologias e os negócios evoluem, as vezes em direções diferentes, conceitos novos são criados e/ou adaptados e eu também posso evoluir tecnicamente para ter visões diferentes e experimentar coisas novas a cada momento, verificando se uma novidade é “apenas hype” ou se realmente vale o investimento. Geralmente nos referimos a sistemas legados como algo ultrapassado, antigo, mas eu vejo que a cada dia de desenvolvimento criamos um legado que pode ser mais fácil ou mais difícil de se adaptar com o passar dos anos.

A partir das respostas podemos ter uma ideia da experiência e visão de alto nível de um desenvolvedor Java. Essas perguntas e respostas podem variar muito mesmo e são pontos de vista técnicos com base na visão teórica e prática de cada profissional. Na minha visão, arquitetura engloba diversos assuntos e podemos ter diversos debates sobre pontos de vista e vista de pontos aqui.

Para saber mais

• Arquitetura Limpa: o Guia do Artesão Para Estrutura e Design de Software
• Clean Architecture: A Craftsman’s Guide to Software Structure and Design
• Domain-Driven Design: Tackling Complexity in the Heart of Software (English Edition)

Gostou? Foi útil? Concorda ou discorda de algum ponto? Comenta ai e vamos aprender mais juntos.

Espero que te ajude 😉