Quando comecei o SaaS contabil da ACCENSEO no inicio de 2025, eu sabia que ficaria sozinho codando por 14 meses em mais de 200 mil linhas de código, num dominio regulado que não perdoa atalhos (PCG, CGI, e-fatura 2026-2027). A armadilha classica nesse tipo de codebase e comecar com um split por camada tecnica (controllers / services / repositories) que vira ingerivel passados 30 modulos. Eu precisava de uma arquitetura que aguentasse 2 anos sem divida estrutural.

Apostei numa arquitetura feature-driven desde o primeiro commit: 42 modulos autonomos em `src/features/` (banco, faturamento, contabilidade, fiscal, folha, assistente IA, reporting, juridico, OCR...), cada um com seus proprios componentes, hooks, services, models e types. `src/app/` so contem o roteamento Next.js, nunca lógica de negocio. Do lado dos dados, 91 modelos Prisma organizados em torno das entidades de dominio (não em torno das tabelas SQL), com 63 enums tipados, e 6 papeis diferenciados controlados pelo Better Auth. Para os contratos cross-feature, expus um `index.ts` por feature definindo a superficie pública consumivel - todo o resto fica interno ao modulo.

382 rotas API geradas, novas features adicionadas em dias em vez de semanas, e as fronteiras modulo/feature sobreviveram a varios refactorings importantes (upgrade Next.js 16, migracao React 19, adicao da extensao Chrome Teledec) sem precisar mexer na estrutura geral.

O que validei nesse projeto e que uma boa arquitetura torna o crescimento linear em vez de exponencial: na 30a feature eu estava tao rápido quanto na 5a. E exatamente a promessa que preciso sustentar no próximo papel CTO scale-up - e já a estressei em solo, o que torna a transposicao para um time muito mais credivel.

O extranet European Sourcing era o back-office central do maior salao online europeu de objetos publicitarios - 15 sub-projetos interconectados, base MySQL compartilhada de 15 GB em 97 tabelas, 7 linguas, 800 fornecedores, e alguns catalogos como SOL's traziam 15.000 variacoes para um único produto. A v1, escrita em 2008-2013 num framework MVC PHP caseiro, não acompanhava mais o ritmo: cada adicao de negocio custava cada vez mais.

Em 14 de marco de 2016, comecamos a v2 "Rebirth" em Symfony 3.1, com PostgreSQL no lugar do MySQL, RabbitMQ para mensageria assincrona, e principalmente 2 bundles compartilhados - ESCoreBundle (entidades, auth, sistema de arquivos) e ESSourcingBundle (lógica de negocio) - para consolidar o que os 15 sub-projetos duplicavam. Para industrializar as telas de admin, montei um sistema de listas genericas (EntityList) com colunas configuraveis, ações em massa, ações por linha e paginacao. No lado dos formularios, entreguei mais de 70 Form Types Symfony cobrindo produtos, variantes, marcacoes estaticas e dinamicas com perfis, atributos simples / multiplos / grupos, categorias, palavras-chave, labels com sinonimos, assinaturas e workflows de import-export.

A v2 rodou mais de 5 anos em produção (2016-2021), alimentando 37 conectores de import automatizados (Pixika, Makito, Midocean, BIC, Paul Stricker, Clipper, TopTex, Cybernecard...), e a pattern library posta nessa ocasiao foi reutilizada por todos os apps a jusante sem precisar reescrever a arquitetura uma única vez.

Esse projeto me ensinou a compartilhar sem acoplar: os bundles compartilhados ficaram estaveis enquanto cada sub-projeto evoluia no próprio ritmo. E o padrao que rejogo hoje no monorepo Turborepo da ACCENSEO e que vou impor na próxima plataforma scale-up - o custo de uma boa fatoracao e baixo, o custo de uma ma fatoracao e toxico em 10 anos.

Na refatoracao da Fleurance Nature em 2017 na Smile, herdei uma plataforma Magento Enterprise Edition 1.10 carregada até o limite: 1.040 arquivos PHP modificados, 60 modulos custom acumulados, 3 storefronts (Fleurance Nature France, International, Mincifine) para servir com uma matriz tarifaria EAV compartilhada entre 4 grupos de clientes (anonimos, geral, assinantes fieis, comites de empresa) - ou seja, 12 combinacoes tarifarias ativas. As proprias specs passaram por 7 versoes em 2 meses (de 30 a 50 paginas) a medida que descobriamos as regras de negocio escondidas no código legado.

Recusei a tentacao do big-bang. Coloquei um split limpo backend/frontend nos 3 storefronts, portei ElasticSearch para o Magento EE 1.10 substituindo Solr (autocomplete, navegacao por facetas, categorias virtuais), e impus em cada modulo custom o respeito aos padroes Observer/Strategy para permanecer PCI-aware sem tocar no core do Magento. Para garantir os deploys, montei uma suite de regressao completa nos 3 sites antes de cada release, porque mexer num modulo podia impactar potencialmente as 12 matrizes tarifarias.

A plataforma refatorada se manteve mais de 5 anos em produção sem nova reescrita arquitetural, zero incidente de seguranca major durante e apos a migracao, e o cache Varnish ficou operacional ao longo de todo o processo apesar da sensibilidade do site live.

O que aprendi nesse projeto e que as fronteiras modulo/core são o que faz uma codebase sobreviver as trocas de prestador e aos upgrades - não a qualidade do código em si. Em cada auditoria de CTO advisory que conduzo hoje na ACCENSEO, e a primeira coisa que olho na codebase do cliente.