O problema não é só construir. É construir para quê.
Toda equipe já viveu esse paradoxo: o produto parece ter mercado, a tecnologia parece saudável, e ainda assim o projeto começa a desandar. O motivo raramente é um único grande erro. Quase sempre é uma confusão entre o que existe no mercado e o que existe no sistema. Em um caso, o erro é superestimar demanda. No outro, é concentrar responsabilidades até que tudo vire uma bola de neve. Em ambos, a falha central é a mesma: tentar tratar complexidade como se fosse simplicidade.
Pense em uma startup que quer lançar uma plataforma de gestão financeira. O time pode cair em duas armadilhas ao mesmo tempo. Primeiro, imaginar que o mercado inteiro é acessível, quando na prática apenas um segmento específico compra, usa e recomenda o produto. Segundo, construir uma aplicação em que controllers fazem validação, regra de negócio, persistência e formatação de resposta, enquanto models acumulam quase toda a inteligência do sistema. O resultado é previsível: um mercado imaginário e uma arquitetura inchada.
A conexão mais profunda entre estratégia de mercado e arquitetura de software é esta: ambos exigem recorte. Você precisa recortar o público certo, o problema certo e o caminho certo até a adoção. E, dentro do código, precisa recortar responsabilidades, fluxos e camadas para que o sistema continue entendível amanhã. Sem recorte, você não tem estratégia, só ambição misturada com ruído.
Escopo não é limitação, é a forma mais elegante de tornar a complexidade administrável.
TAM, SAM e SOM também existem dentro do sistema
TAM, SAM e SOM costumam aparecer em discussões sobre mercado, captação e go to market. Mas essa lógica pode ser mais útil do que parece, inclusive para pensar software. O TAM representa o mercado total possível. O , a parcela realmente atendível. O , a fatia que você consegue conquistar no curto prazo. Esse modelo é poderoso porque força uma pergunta que muitas equipes evitam: “De tudo o que é teoricamente possível, o que é realisticamente relevante agora?”
Esse mesmo raciocínio pode ser aplicado à arquitetura. Todo sistema começa com um TAM de funcionalidades: a lista infinita de coisas que poderiam ser feitas. Depois vem o SAM técnico, aquilo que faz sentido para o contexto atual, dadas as restrições de time, prazo, stack e domínio. Por fim, existe o SOM de engenharia, o subconjunto que pode ser entregue com qualidade, mantido com tranquilidade e evoluído sem sofrimento.
Essa lente muda a conversa. Em vez de perguntar “podemos colocar isso no sistema?”, a pergunta vira “isso pertence ao escopo atendível agora?”. Em vez de tentar transformar o model em um depósito de regras, persistência, validação e integração, você começa a separar o que é essencial do que é apenas conveniente. O modelo deixa de ser um lugar de acumulação e passa a ser um lugar de significado.
Considere um exemplo simples. Um e commerce quer adicionar cálculo de frete, desconto progressivo e regra de fidelidade. O TAM de possibilidades é enorme: várias transportadoras, múltiplas promoções, dezenas de exceções regionais. Mas o SAM pode ser mais estreito: apenas uma transportadora, um tipo de desconto e um único programa de fidelidade. O SOM, então, é o que de fato pode ser lançado agora sem quebrar a base de código. Uma arquitetura saudável nasce exatamente dessa disciplina.
A mesma confusão que faz uma empresa dizer “nosso mercado é enorme” também faz um desenvolvedor dizer “nosso model consegue fazer isso”. Nos dois casos, o verbo conseguir é enganoso. Conseguir não é o mesmo que sustentar. Um mercado pode existir, mas não ser acessível. Um código pode rodar, mas não ser saudável.
A verdadeira responsabilidade única não é técnica, é estratégica
O princípio da responsabilidade única costuma ser apresentado como uma regra de design: classes e métodos devem ter somente uma responsabilidade. Isso é útil, mas incompleto. A versão mais profunda do princípio é esta: cada componente deve servir a um único motivo de mudança. E isso não vale só para classes. Vale para produtos, times, páginas de venda, funis e mercados.
Quando um controller faz validação, aplica regra de negócio, manipula dados e decide como responder, ele não é apenas “feio”. Ele está misturando motivos de mudança diferentes. Se a regra comercial mudar, o controller muda. Se a integração com o banco mudar, o controller muda. Se a API externa mudar, o controller muda. O mesmo acontece quando uma empresa tenta vender para todos os perfis ao mesmo tempo: mensagens diferentes, dores diferentes, preços diferentes, canais diferentes. A marca vira um controller inchado, tentando decidir tudo sozinha.
O paralelo mais útil aqui é pensar em fronteiras de responsabilidade. Em arquitetura, fronteiras impedem que tudo dependa de tudo. Em mercado, fronteiras evitam que a proposta de valor dependa de uma abstração genérica demais. Uma equipe que tenta servir “pequenas empresas” e “grandes corporações” com a mesma promessa normalmente não está sendo inclusiva, está sendo imprecisa. De forma semelhante, uma classe que faz tudo não está sendo prática, está sendo frágil.
Há uma razão para isso parecer contraintuitivo. O ser humano tende a admirar sistemas abrangentes. Queremos soluções que façam mais, cubram mais e resolvam mais. Mas sistemas abrangentes demais costumam ficar piores em duas dimensões decisivas: clareza e manutenção. O produto deixa de ser nítido, e o código deixa de ser confiável.
Quando tudo é responsabilidade de tudo, nada é realmente compreendido.
Essa é a ponte real entre mercado e software: o excesso de amplitude destrói a capacidade de decisão. No mercado, isso aparece como posicionamento difuso. No código, aparece como acoplamento. Em ambos, a cura não é mais força, é mais delimitação.
“Modelo gordo, controller fino” é uma lição de mercado disfarçada
A recomendação de controllers finos e models mais expressivos costuma ser vista apenas como boas práticas de Laravel. Mas, no fundo, ela ensina algo mais universal: o lugar certo para a complexidade é o lugar em que ela faz sentido.
Um controller deve coordenar. Ele não deveria ser o cérebro do sistema, apenas o maestro. Quem tenta concentrar regras no controller está tratando coordenação como se fosse inteligência. Isso é como um time de produto colocar toda a estratégia no slide de apresentação, em vez de distribuí-la em decisões concretas de segmentação, mensagem, canal e oferta. A apresentação fica elegante, mas a execução vira caos.
Já o model, quando “gordo” no sentido certo, pode concentrar domínio, invariantes e regras que pertencem naturalmente à entidade. Não se trata de inflar objetos, e sim de colocar cada coisa no seu lugar sem vergonha de deixar o domínio falar sua própria linguagem. O perigo não é o model ter lógica. O perigo é ele virar lixeira de responsabilidades que não pertencem ao domínio.
Imagine um sistema de assinaturas. Há regras como: cancelar após a data de renovação, aplicar desconto apenas no primeiro ciclo, bloquear reativação em certos planos. Essas regras têm relação com o domínio, então precisam viver onde o domínio possa ser entendido. Por outro lado, ler requisições, converter formatos e lidar com detalhes de transporte de dados não fazem parte da substância do negócio. Misturar tudo produz um código que parece prático até o dia em que a regra muda. Aí a praticidade cobra juros.
A analogia com TAM, SAM e SOM é direta. O model deve focar no SAM semântico do sistema, isto é, nas regras que realmente definem o negócio atendido. O controller deve operar dentro do SOM operacional, isto é, o que pode ser executado de forma simples e confiável naquela interação. Quando cada camada tenta abraçar o universo, a arquitetura perde a capacidade de refletir o mercado real.
Essa é uma ideia poderosa porque muda o objetivo da organização do código. Não se organiza apenas para “ficar bonito”. Organiza-se para expressar prioridades. Uma boa arquitetura é uma teoria prática sobre o que importa mais, o que muda mais, e o que deve permanecer estável.
O mapa mental que une mercado e arquitetura: amplitude, acesso e execução
A forma mais útil de juntar essas ideias é pensar em três níveis sempre que você cria um produto ou uma estrutura de código:
Amplitude: tudo o que poderia existir.
Acesso: tudo o que é realmente alcançável agora.
Execução: tudo o que pode ser feito sem comprometer o futuro.
No mercado, a amplitude é o TAM. O acesso é o SAM. A execução é o SOM. No software, a amplitude é o conjunto de possibilidades do domínio. O acesso é o conjunto de casos que seu sistema realmente precisa tratar agora. A execução é a forma de implementar sem transformar simplicidade em dívida técnica.
Esse mapa resolve uma confusão recorrente: equipes acreditam que “pensar grande” significa desenhar tudo de uma vez. Na prática, pensar grande significa construir um recorte inteligente. Um produto vencedor não é aquele que serve qualquer um. É aquele que entende profundamente um recorte específico e entrega algo nítido, útil e confiável. Uma base de código saudável não é aquela que centraliza tudo. É aquela que permite que cada decisão viva no lugar certo.
Há também uma consequência organizacional importante. Times que confundem TAM com SAM acabam priorizando features que parecem impressionantes, mas não mudam adoção. Times que confundem responsabilidade única com isolamento absoluto acabam criando microcomponentes difíceis de compor. O ponto não é fragmentar por esporte. É criar unidades coerentes de decisão.
Pense em uma cozinha profissional. O salão não prepara comida, a chapa não negocia com cliente, o estoque não inventa o menu. Cada área tem uma responsabilidade clara, mas todas servem ao mesmo objetivo. Um restaurante bem operado conhece seu mercado atendível, seu menu possível e seu ritmo de execução. Um sistema bem desenhado funciona da mesma forma. O mercado define o que faz sentido oferecer. A arquitetura define como oferecer sem colapsar.
Como aplicar isso amanhã: menos ambição abstrata, mais fronteira concreta
Se você lidera produto, tecnologia ou ambos, a pergunta útil não é “como fazer mais?”. É “onde está a fronteira certa?”. Essa fronteira aparece no mercado quando você escolhe um segmento com dor real. Aparece no código quando você define quem decide o quê, e onde cada regra vive.
Uma boa prática é revisar qualquer iniciativa nova com estas perguntas:
Qual é o TAM desta ideia, isto é, tudo o que ela poderia ser?
Qual é o SAM, isto é, o que realmente faz sentido para nosso contexto atual?
Qual é o SOM, isto é, o que conseguimos lançar com qualidade sem criar uma bomba-relógio?
Depois faça a mesma triagem na arquitetura:
Qual parte do sistema pertence ao domínio?
Qual parte apenas coordena fluxo?
Qual parte é infraestrutura ou detalhe técnico?
Se uma regra de negócio estiver vivendo em uma camada errada, trate isso como um sinal de mercado também. Talvez o sistema esteja tentando atender casos que não deveriam ser prioridade agora. Talvez a estrutura esteja sinalizando uma ambição não filtrada.
O efeito dessa disciplina é surpreendente. Produtos ficam mais fáceis de vender porque a proposta é mais clara. Sistemas ficam mais fáceis de manter porque a lógica ficou mais localizada. Decisões futuras ficam mais baratas porque o motivo de mudança foi isolado desde o início.
O recorte certo não empobrece o projeto. Ele o torna possível.
Key Takeaways
Separe amplitude de viabilidade: nem tudo que pode existir deve entrar no produto, e nem toda regra deve entrar na mesma camada.
Use TAM, SAM e SOM como filtro de decisão: pergunte o que é teoricamente possível, o que é atendível e o que é executável agora.
Trate responsabilidade única como fronteira de mudança: cada classe, método, time ou proposta deve ter um motivo dominante para mudar.
Mantenha o controller coordenando, não pensando: coordenação, validação básica e roteamento são diferentes de regra de negócio.
Coloque a complexidade onde ela pertence: o domínio deve conter significado, não bagunça; a infraestrutura deve conter detalhes, não estratégia.
O que um bom produto e um bom sistema têm em comum
No fim, mercado e arquitetura obedecem à mesma lei silenciosa: clareza nasce de limites bem escolhidos. O erro não é querer crescer, nem querer abstrair. O erro é achar que crescimento exige indefinição, e que abstração exige centralização. Na verdade, o melhor crescimento vem do foco, e a melhor abstração vem da separação.
Se você olhar de novo para TAM, SAM e SOM, verá que eles não são apenas métricas comerciais. São uma disciplina de pensamento. E se olhar para responsabilidade única, modelos bem colocados e controllers finos, verá que isso não é apenas uma técnica de programação. É uma forma de respeitar a realidade do sistema.
Talvez essa seja a conexão mais valiosa entre os dois temas: um bom produto só escala quando sabe o que não é, e um bom código só cresce quando sabe o que não faz. A maturidade, nos dois casos, começa quando paramos de confundir abrangência com inteligência.
A pergunta que vale levar para a próxima reunião, ou para o próximo refactor, é simples e exigente: qual é o recorte certo para que este sistema continue fazendo sentido daqui a um ano?
O Mercado é o Seu Código: por que escopo e estrutura quebram do mesmo jeito | Glasp
