Escolha da stack
Linguagem, framework e banco escolhidos pelo problema, pela equipe que vai manter e pelo que a sua hospedagem suporta — não pela novidade do ano.
Método YveTech de Engenharia · Etapa 02
Arquitetura que aguenta o próximo ano
Stack, limites de domínio, modelo de dados e estratégia de integração definidos antes de construir — e registrados por escrito, para que nenhuma decisão dependa da memória de um único desenvolvedor.
Arquitetura é a soma das decisões caras de mudar depois
Trocar a cor de um botão custa minutos. Trocar o modelo de dados de um sistema em produção custa meses.
Todo sistema tem arquitetura. A diferença é se ela foi escolhida ou herdada — se alguém decidiu como os dados se organizam e onde ficam as fronteiras, ou se isso foi se formando conforme as urgências apareceram. A segunda é a origem da frase que ouvimos com frequência: "qualquer mudança agora custa caro e demora demais".
Nesta etapa definimos o que é caro de mudar: como o domínio se divide, como os dados se relacionam, o que é síncrono e o que pode esperar, por onde entram e saem as integrações, como o sistema se comporta quando um terceiro cai. Também definimos o que não vamos fazer — porque quase toda arquitetura ruim começa como uma arquitetura ambiciosa demais para o problema.
Cada decisão vira um registro curto: o que foi decidido, quais alternativas foram consideradas e por que esta venceu. É o documento que permite a outra equipe assumir o sistema — inclusive a sua — sem precisar entrevistar quem escreveu o código.
A pergunta que fazemos em cada decisão não é "qual é a melhor tecnologia?". É "quem vai manter isso daqui a dois anos, e com essa escolha ainda vai conseguir?".
O que fica definido nesta etapa
Seis decisões que orientam tudo o que vem depois.
Modelo de dados
Como as entidades se relacionam, o que é histórico e o que é estado atual, e o que precisa ser auditável desde o primeiro dia.
Limites de domínio
Onde termina vendas e começa faturamento. Fronteira clara é o que permite mexer em uma parte sem quebrar a outra.
Estratégia de integração
Como o sistema conversa com ERP, gateway, marketplace e órgão público — e o que acontece quando o outro lado não responde.
Registro de decisões
Cada escolha estrutural com alternativa e motivo. Curto, datado e versionado junto com o código.
Plano de crescimento e custo
O que muda quando o volume dobra, e quanto isso custa por mês. Estimado antes, não descoberto na fatura.
Como a arquitetura é apresentada
Um desenho que o time técnico usa e que o dono do negócio consegue ler.
Como a etapa acontece
De uma a três semanas, com prova técnica onde o risco é real.
Requisitos que não aparecem na tela
Volume, concorrência, disponibilidade, auditoria, retenção e LGPD. São eles que descartam metade das opções antes de qualquer gosto pessoal.
Desenho e alternativas
Montamos duas ou três opções viáveis, com o que cada uma cobra em complexidade, custo e prazo.
Prova técnica
Onde o risco é real — uma integração duvidosa, um volume incomum — construímos um teste pequeno antes de apostar o projeto nele.
Documento de arquitetura
O desenho final, os registros de decisão e o padrão de código que a equipe vai seguir. Entregue, não prometido.
O que evitamos por princípio
Escolhas que parecem sofisticadas na apresentação e cobram caro na manutenção.
- Complexidade sem necessidade — dividir em serviços um sistema que cabe em um só.
- Tecnologia sem quem mantenha — framework que só uma pessoa da região domina.
- Amarra a um fornecedor — recurso proprietário que impede trocar de nuvem depois.
- Decisão sem registro — escolha estrutural que só existe na cabeça de quem escreveu.
Tecnologias que usamos
Ferramentas escolhidas pelo problema — nunca por moda.
- TypeScript, Node.js e React — a base da maior parte dos sistemas web que entregamos.
- Python, Java e .NET — quando o domínio, a equipe do cliente ou a integração pedem.
- PostgreSQL e Redis — dado relacional com integridade e cache onde a conta pesa.
- Docker e infraestrutura como código — ambiente replicável, do notebook à produção.
Decisões de arquitetura e o que cada uma cobra
Não existe escolha sem contrapartida. O que existe é escolha com a contrapartida explicada antes.
| Decisão | Quando faz sentido | O que cobra em troca |
|---|---|---|
| Sistema único (monolito) | a maioria dos sistemas de PME: um time, um domínio | exige disciplina de fronteira interna para não virar um bolo só |
| Serviços separados | times independentes ou partes com escala muito diferente | multiplica infraestrutura, monitoramento e complexidade de deploy |
| Banco relacional | dado com integridade e relatório — quase sempre | exige modelagem cuidadosa antes, não depois |
| Fila de processamento | tarefa lenta que não pode travar a tela do usuário | mais uma peça para monitorar, e ordem de execução deixa de ser óbvia |
| Nuvem gerenciada | quer começar rápido, sem equipe de infraestrutura | custo mensal que cresce com o uso e precisa ser acompanhado |
| Servidor próprio | já existe infraestrutura e time de TI | atualização, backup e continuidade passam a ser seus |
Compromissos desta etapa
O que combinamos antes de começar — e cobramos de nós mesmos durante o projeto.
Registradotoda decisão estrutural, com alternativa e motivo
2–3 opçõesavaliadas antes de escolher
Sem amarranada que impeça trocar de fornecedor ou de nuvem
Custo estimadode infraestrutura, antes de construir
Perguntas frequentes sobre arquitetura
As dúvidas que mais aparecem nesta etapa. Sobre prazo, forma de cobrança e contrato, veja as perguntas frequentes da YveTech.
Vocês usam sempre a mesma stack?
Não, mas também não recomeçamos do zero a cada projeto. Temos um conjunto que dominamos bem — e é o que costuma sair mais barato para você, porque a equipe é produtiva nele desde o primeiro dia. Quando o problema pede outra coisa, mudamos e explicamos por quê.
Meu sistema precisa de microserviços?
Quase certamente não. Microserviços resolvem um problema de organização de times grandes, e cobram um preço alto em infraestrutura e operação. Para a maioria das empresas que atendemos, um sistema único bem dividido por dentro entrega o mesmo resultado com uma fração do custo.
Como saber se aguenta o crescimento?
Definimos na etapa qual é o volume esperado e testamos o ponto de risco antes de construir tudo. Também deixamos escrito o que precisa mudar quando o volume dobrar — para que crescer seja uma obra prevista, e não uma emergência.
Se eu quiser trocar de fornecedor depois, consigo?
Essa é uma das razões de a etapa existir. Código no seu repositório, documentação de arquitetura entregue, nada de recurso proprietário que prenda a uma nuvem específica. Sair deve ser possível — e o fato de ser possível é o que mantém a relação saudável.
Tem um sistema que trava a cada mudança?
Uma avaliação de arquitetura mostra o que está travando e o que dá para destravar sem reescrever tudo.
Continue explorando
As quatro etapas do método e os três recortes da operação — cada uma com o seu próprio detalhamento.
Engenharia de SoftwareVoltar à visão geral da área
Descoberta e escopoO processo real virando backlog, escopo e preço fechados
Desenvolvimento em ciclosEntrega navegável a cada duas semanas, com homologação aberta
Esteira e sustentaçãoDeploy automatizado, monitoramento e correção com prazo em contrato
Da linha de código ao deployO caminho de uma alteração até entrar em produção
Revisão de códigoO segundo par de olhos que impede o erro de nascer
Ambiente de Engenharia de SoftwareRepositório, ambientes, esteira e acessos — a base do projeto