Como Go e PostgreSQL diferem de Node.js e Supabase

Um gerador de IA pode produzir um protótipo de SaaS convincente com qualquer uma das stacks. A diferença importante aparece depois que clientes criam dados problemáticos, tentativas chegam fora de ordem, um plano de consulta muda e alguém precisa explicar uma falha em produção. Escolha a stack cujos modos de falha sua equipe consegue enxergar e corrigir, não a que criou a primeira tela mais rápido.

Go com PostgreSQL oferece uma divisão explícita entre aplicação e banco de dados. Você decide como as solicitações entram, onde as transações começam, como o SQL é estruturado e como o binário é executado. Node.js com Supabase oferece um ambiente JavaScript ou TypeScript mais um conjunto gerenciado de serviços centrados no PostgreSQL, incluindo autenticação, armazenamento, recursos em tempo real, APIs geradas e operação hospedada. A segunda opção elimina grande parte da configuração, mas também muda onde a lógica da aplicação fica e quais decisões operacionais passam a ser suas.

Não são dois pacotes equivalentes de linguagens de programação. Um geralmente é um backend montado de forma deliberada; o outro costuma ser uma arquitetura de produto gerenciada. Comparar sintaxe ou contar arquivos gerados não resolve a decisão.

Como as duas stacks dividem responsabilidades

A primeira escolha é quanto do contrato do backend você quer assumir. Com Go e PostgreSQL, seu serviço normalmente cuida do tratamento HTTP, das decisões de autorização, validação, limites de transação, trabalho em segundo plano e acesso ao banco de dados. O PostgreSQL cuida do estado durável e das garantias do banco. Hospedagem, identidade, armazenamento de objetos e implantação continuam sendo escolhas separadas, a menos que você os adicione.

Uma aplicação Node.js com Supabase distribui essas responsabilidades. Um serviço Node ou uma função serverless pode conter lógica personalizada, enquanto o Supabase fornece PostgreSQL hospedado, Auth, Storage, Realtime, Edge Functions e uma camada de API gerada a partir do banco de dados. Às vezes, um cliente de navegador pode falar diretamente com o Supabase sob Row Level Security (RLS). Isso pode eliminar código comum de endpoints, mas a política do banco passa a fazer parte do limite público da aplicação.

Essa distinção importa mais do que Go versus TypeScript. Um handler REST gerado em Go e uma chamada a tabela gerada pelo Supabase podem parecer igualmente rápidos. O handler em Go ainda oferece um lugar evidente para inspecionar uma solicitação, aplicar uma regra, abrir uma transação e emitir um rastreamento. A chamada direta à tabela pode passar pelo comportamento da API gerada e pela RLS antes de tocar nos dados. Esse caminho é menor no código-fonte, não necessariamente mais simples em produção.

Trate recursos gerenciados como compromissos arquiteturais, não como acessórios gratuitos. Se o Auth emite a identidade usada pela RLS, as políticas de Storage se referem à mesma identidade e as assinaturas do Realtime dependem de alterações no banco, substituir uma parte depois afeta vários contratos. Esse acoplamento pode fazer todo sentido. Uma equipe pequena costuma se beneficiar ao adquirir um conjunto coerente de serviços. O problema começa quando a equipe acredita que escolheu apenas um banco de dados.

Go e PostgreSQL também podem ocultar dependências se o gerador construir um framework interno cheio de repositórios, camadas de serviço e auxiliares genéricos. Ter o código só ajuda quando engenheiros conseguem segui-lo. Uma abstração gerada pode tornar uma atualização SQL simples mais difícil de encontrar do que uma política RLS. Peça ao gerador o menor limite legível e inspecione o resultado antes de adicionar outra camada.

A forma da carga de trabalho deve decidir o runtime

Go se encaixa em serviços com concorrência contínua, trabalho misto em segundo plano, expectativas previsíveis de memória e endpoints cuja latência depende de várias operações coordenadas. Goroutines simplificam a E/S concorrente, e um binário compilado oferece aos operadores uma unidade compacta de implantação. Isso não torna todos os serviços em Go rápidos. SQL ruim, concorrência ilimitada e timeouts ausentes ainda falham de maneiras conhecidas.

Node.js se encaixa em cargas dominadas por E/S de rede, handlers curtos de solicitações, processamento de eventos e equipes já produtivas em TypeScript. Seu loop de eventos lida bem com muitas conexões em espera. Trabalho pesado de CPU bloqueia o progresso se for executado na thread principal, portanto transformações de imagem, análise de documentos grandes ou computação local ligada a modelos exigem worker threads, workers separados ou outro serviço. Código gerado costuma ignorar esse limite porque a entrada da demonstração é pequena.

Supabase pode eliminar trabalho de aplicação para acesso comum a dados, fluxos de autenticação, armazenamento de arquivos e atualizações em tempo real guiadas pelo banco. É uma boa opção para um produto cuja primeira versão é composta principalmente por contas, formulários, registros, permissões e notificações. É menos adequado quando cada operação coordena muitos sistemas externos, exige jobs longos ou aplica regras de domínio que não pertencem a políticas do banco ou a pequenas edge functions.

Considere quatro perguntas sobre a carga de trabalho antes de escolher:

• Uma ação do usuário exige uma única operação de registro ou uma transação entre vários agregados?
• As solicitações passarão a maior parte do tempo esperando por redes ou realizarão trabalho relevante de CPU?
• Os jobs sobrevivem a uma solicitação HTTP e exigem tentativas, leases, cancelamento ou acompanhamento de progresso?
• O banco consegue expressar a autorização de forma clara ou a permissão depende de estado externo e histórico do fluxo?

Uma importação de cobrança ilustra a divisão. Fazer upload de um arquivo, armazenar seus metadados e mostrar o progresso pode se encaixar em qualquer stack. Analisar milhares de linhas irregulares, eliminar duplicatas comparando com faturas existentes, aplicar regras específicas de cada conta e retomar após uma falha parcial exige um modelo explícito de job. Go é confortável para esse worker. Node também é viável quando a equipe isola o trabalho de CPU e usa uma fila durável. Supabase continua útil como camada de banco e armazenamento, mas não faz desaparecer a semântica do job.

Não escolha Go apenas porque o desempenho talvez importe. A maioria dos SaaS novos enfrenta erros de consulta, produto e operação antes de a capacidade do runtime se tornar uma limitação. Escolha Go quando a forma do serviço se beneficia de concorrência explícita e processos de longa duração. Não escolha Node apenas porque um modelo de IA gera TypeScript com facilidade. Escolha-o quando a carga de trabalho e as pessoas que operam o sistema se beneficiam de uma única linguagem em toda a fronteira web.

A habilidade da equipe altera o custo do código gerado

A melhor stack é aquela que sua equipe consegue depurar depois que o gerador erra. A velocidade de geração vale pouco se os revisores não conseguem reconhecer uma atualização perdida, uma política insegura ou uma promessa que nunca foi aguardada.

Uma equipe com experiência em produção com Go normalmente prefere handlers explícitos, estruturas de domínio tipadas, cancelamento com context.Context e SQL direto. O compilador de Go detecta uma classe útil de erros de integração, mas não consegue provar que uma transação protege as linhas certas ou que uma verificação de autorização corresponde à regra de negócio. Os revisores ainda precisam de bom julgamento sobre banco de dados.

Uma equipe focada em TypeScript pode avançar rápido por uma base Node e Supabase porque os tipos de frontend e backend compartilham ferramentas conhecidas. Os tipos de banco gerados pelo Supabase melhoram o retorno do editor quando o esquema é a fonte. Tipos não aplicam validação em tempo de execução por conta própria, e uma asserção de tipo pode silenciar justamente o alerta de que um revisor precisava. Código gerado costuma presumir que a entrada externa já tem a forma desejada.

Habilidade também inclui o vocabulário operacional da equipe. Alguém consegue ler EXPLAIN (ANALYZE, BUFFERS) sem adivinhar? Alguém distingue uma expressão RLS USING de uma expressão WITH CHECK? Alguém consegue rastrear um handler assíncrono do Node por promessas rejeitadas? Alguém consegue inspecionar a saturação do pool de conexões em Go e propagar o cancelamento? A stack que gera mais respostas positivas traz menos risco operacional.

Equipes pequenas devem contar a troca de contexto. Go mais PostgreSQL pode exigir escolhas separadas para migrações, autenticação, armazenamento, filas, observabilidade e hospedagem. Cada escolha pode ser boa e ainda impor trabalho de integração. Node mais Supabase concentra uma parcela maior dessa superfície em um só produto e mantém TypeScript perto do frontend. A atenção poupada é real.

O custo oposto é o conhecimento especializado. O acesso direto do navegador sob RLS pede que todos os revisores entendam a política do banco como autorização da aplicação. Edge functions introduzem um limite de runtime diferente de um servidor Node convencional. Painéis hospedados simplificam o trabalho rotineiro, mas podem incentivar pessoas a alterar o estado de produção fora de migrações versionadas. Nenhum desses custos desqualifica o Supabase. Inclua-os na estimativa.

Quando ninguém na equipe operou qualquer uma das stacks, prefira o desenho com menos partes móveis independentes e documente uma rota de saída. Para um SaaS orientado a registros, isso geralmente significa Supabase. Para um backend baseado em jobs, integrações e fluxos personalizados, um pequeno serviço em Go com PostgreSQL gerenciado pode ser mais fácil de entender do que lógica espalhada entre chamadas do cliente, políticas, funções e gatilhos.

Controle de consultas vira controle do produto

Escolha Go com acesso direto ao PostgreSQL quando a forma do SQL e o comportamento das transações forem centrais para o produto. Escolha o acesso a dados gerado pelo Supabase quando o CRUD comum predominar e a RLS conseguir expressar o modelo de segurança sem contorções.

A documentação do PostgreSQL é precisa sobre isolamento de transações: Read Committed é o padrão, e dois comandos sucessivos na mesma transação podem ver dados confirmados diferentes. Equipes muitas vezes repetem a frase reconfortante de que uma transação torna operações seguras sem especificar o nível de isolamento e o comportamento de bloqueio. Uma transação agrupa trabalho. Ela não evita automaticamente todas as condições de corrida.

Suponha que dois workers tentem assumir a próxima exportação pendente. Uma leitura seguida de atualização pode permitir que ambos observem a mesma linha. Faça a reserva em uma única operação de banco e use bloqueio de forma deliberada:

BEGIN;

WITH next_job AS (
  SELECT id
  FROM export_jobs
  WHERE status = 'pending'
  ORDER BY created_at
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
UPDATE export_jobs AS j
SET status = 'running',
    started_at = now(),
    worker_id = $1
FROM next_job
WHERE j.id = next_job.id
RETURNING j.id, j.account_id, j.payload;

COMMIT;

O resultado é uma única linha assumida com id, account_id e payload, ou zero linhas quando não há job disponível. SKIP LOCKED é adequado para consumidores semelhantes a filas que podem assumir linhas diferentes. Não é uma cura geral para leituras voltadas ao usuário, pois omite intencionalmente linhas bloqueadas.

Em Go, essa instrução pode ficar em um repositório ou pacote de consultas, com transação explícita e prazo de cancelamento. Em Node, um cliente de banco do lado do servidor pode executar uma função ou chamada SQL equivalente. Com uma API Supabase gerada, lógica complexa de bloqueio normalmente vai para uma função PostgreSQL exposta via RPC. Continua sendo PostgreSQL sólido, mas os revisores precisam saber que devem procurar em migrações e funções do banco, não no handler da solicitação.

A RLS merece a mesma precisão. O PostgreSQL avalia políticas por tabela e comando. Uma cláusula USING controla quais linhas existentes um comando pode ver, enquanto WITH CHECK controla quais linhas novas ou alteradas ele pode criar. Uma política que filtra leituras não expressa automaticamente todos os invariantes de inserções e atualizações. Teste políticas com pelo menos uma identidade anônima, um membro comum, um membro de outro locatário e uma função de serviço privilegiada.

CRUD gerado atrai porque elimina código repetitivo de endpoints. Mantenha-o para operações cujo contrato realmente tem forma de tabela. Coloque invariantes entre vários registros, idempotência e transições de fluxo atrás de um limite de servidor ou de uma função de banco cuidadosamente desenhada. Se a regra de produto exige um parágrafo para ser explicada, espalhá-la pelo código do cliente e por várias políticas RLS prolongará o próximo incidente.

A portabilidade depende do limite que você preserva

Go e PostgreSQL normalmente oferecem uma saída de implantação mais clara, porque a aplicação é um binário e o banco fala protocolos padrão do PostgreSQL. Você pode executar o serviço em um contêiner ou diretamente em um host e escolher entre muitos provedores de PostgreSQL. A portabilidade ainda depende de evitar extensões exclusivas do provedor, infraestrutura não documentada e suposições sobre o ambiente.

Supabase usa PostgreSQL, o que proporciona uma saída de dados muito melhor do que um banco proprietário. Um dump do banco pode preservar tabelas, índices, funções, gatilhos e boa parte do modelo de políticas. A aplicação completa, porém, também pode depender de claims de token do Auth, convenções de objetos do Storage, comportamento do Realtime, edge functions, semântica de APIs geradas, segredos e configuração de implantação. Mover o banco não é o mesmo que mover o sistema.

Crie um inventário de portabilidade antes do lançamento. Registre cada dependência em banco de dados, identidade, arquivos, trabalho assíncrono, runtime e implantação. Para cada uma, anote o contrato que seu código consome e o custo de substituição. A pergunta útil não é se a migração é possível. Quase tudo é possível com tempo suficiente. Pergunte se uma equipe normal de lançamento conseguiria migrar enquanto continua entregando trabalho de produto.

A exportação de código-fonte importa para SaaS gerado por IA porque a aplicação gerada só é útil se você puder inspecionar e executar o que possui. Koder.ai oferece exportação de código-fonte, além de implantação e hospedagem, para que uma equipe possa revisar a aplicação React e Go/PostgreSQL gerada em vez de tratar a geração como um ponto final opaco. Isso não elimina a necessidade de testar uma compilação limpa fora do ambiente de geração.

Faça essa compilação limpa cedo. Comece com uma máquina vazia ou contêiner mínimo, restaure um banco a partir das migrações, forneça as variáveis de ambiente documentadas, execute testes e atenda uma solicitação representativa. Depois, restaure um backup real em um ambiente que não seja de produção. Equipes que esperam uma mudança do fornecedor ou uma indisponibilidade para testar portabilidade já tomaram a decisão cara.

A localização dos dados também pode determinar a portabilidade. Se contratos exigem que uma aplicação rode em determinado país, confirme que runtime, banco, backups, logs, armazenamento de objetos e acesso de suporte atendem à exigência. Mover apenas o processo web não move o sistema de dados. Koder.ai pode executar aplicações em diferentes países para atender a necessidades de privacidade de dados e transferências internacionais, mas as equipes ainda precisam mapear cada componente que armazena dados em sua própria arquitetura.

A depuração mostra para onde foi a complexidade

Go e PostgreSQL tendem a concentrar a depuração em rastreamentos de solicitações, logs de serviço, sessões de banco e workers de jobs. Node.js e Supabase podem espalhar a mesma investigação entre chamadas do navegador, um processo Node ou edge function, logs da API gerada, Auth, RLS, Realtime e PostgreSQL. Menos linhas de código de aplicação podem significar mais limites para inspecionar.

Uma falha comum começa com uma mudança de esquema aparentemente inofensiva. Uma aplicação gerada adiciona um organization_id anulável, preenche algumas linhas, ativa uma política RLS e altera a consulta do cliente. A conta no caminho ideal funciona. Uma linha antiga permanece nula, então a política a oculta. O cliente recebe um resultado vazio em vez de um erro explícito de autorização e mostra um estado em branco. Uma assinatura em tempo real usa outro filtro e continua anunciando alterações. O suporte vê uma tela que às vezes é preenchida de novo após atualizar a página.

Nada nessa cadeia é incomum. A dificuldade está em observar cada decisão. Quem investiga precisa do sujeito autenticado, claims do token, identificador da solicitação, função do banco, SQL ou operação da API gerada, resultado da política, quantidade de linhas, canal de assinatura e versão do esquema implantado. Se esses fatos estiverem em painéis sem relação entre si, sem um valor compartilhado de correlação de solicitação ou usuário, a equipe reconstrói o incidente por horário.

Um endpoint convencional em Go poderia transformar a organização ausente em erro de domínio antes da consulta, registrar um evento estruturado e retornar um status definido. Essa explicitação ajuda. Ela também depende de o handler ser o único caminho para a tabela. Um endpoint administrativo ou worker esquecido pode ignorar a mesma autorização, a menos que o banco imponha um invariante correspondente.

O desenho com Supabase pode aplicar o isolamento de locatários no PostgreSQL em todos os caminhos do cliente. Isso também ajuda. Seu modo de falha é a invisibilidade da política: um conjunto vazio de linhas pode ser filtragem correta, contexto de identidade errado, dados de migração incompletos ou uma falha na consulta. Crie operações de diagnóstico que distingam esses casos sem desativar a RLS em produção.

Em qualquer uma das stacks, exija quatro campos em todos os caminhos de backend gerados: um identificador de correlação, identificador do ator autenticado, nome da operação e versão do esquema ou da release. Registre durações e contagens de linhas quando elas não revelarem dados sensíveis. Preserve a causa do erro original ao mapeá-la para uma resposta segura ao cliente. Em Node, trate promessas rejeitadas no limite da solicitação e não considere um handler no nível do processo uma forma de recuperação. Em Go, passe o contexto da solicitação para as chamadas ao banco e diferencie cancelamento por prazo de uma falha do banco.

Capacidade de depuração é uma propriedade do desenho. Se o gerador produz código que operadores não conseguem rastrear, peça que ele simplifique o fluxo de controle antes de pedir logs em todos os lugares.

Conveniência de implantação e responsabilidade operacional são diferentes

Supabase costuma vencer a primeira rodada operacional. Uma equipe pode provisionar um projeto e receber um banco de dados com serviços integrados sem montar cada componente. Backups, atualizações, disponibilidade do serviço e monitoramento da plataforma têm padrões gerenciados ou controles do produto. Leia o plano atual e a documentação do provedor para conhecer retenção e limites exatos, pois esses detalhes podem mudar.

Gerenciado não significa sem supervisão. A equipe da aplicação ainda é responsável pelo desenho do esquema, índices, consultas caras, comportamento de conexão, retenção de dados, correção da RLS, segredos, monitoramento da aplicação e testes de recuperação. Também precisa entender cotas e quais falhas exigem suporte do provedor. Um painel que diz que o banco está saudável não informa que o relatório de um locatário faz, por acidente, uma varredura sequencial.

Go e PostgreSQL tornam a responsabilidade mais visível. Se você escolhe PostgreSQL gerenciado, o provedor pode cuidar de boa parte da operação do banco enquanto sua equipe cuida do runtime do serviço. Se hospeda ambos por conta própria, também é responsável por correções, failover, backups, testes de restauração, capacidade e resposta a incidentes. Hospedar por conta própria não é sinal de seriedade. É uma carga operacional que exige pessoas e ensaios.

O gerenciamento de conexões afeta as duas stacks. Um serviço Go de longa duração usa um pool e precisa de limites explícitos para conexões abertas e ociosas, duração das conexões e prazos de solicitação. Funções Node serverless podem criar uma explosão de clientes que sobrecarrega o PostgreSQL, a menos que a arquitetura use um pooler adequado e respeite as limitações do modo de transação. Código gerado que abre um novo cliente por solicitação pode sobreviver a uma demonstração e entrar em colapso durante um pico de tráfego.

Migrações precisam de uma única autoridade. Execute migrações ordenadas e versionadas a partir de uma etapa controlada de implantação. Não deixe cada instância de serviço competir para alterar o esquema na inicialização, nem permita que edições no painel se tornem a verdade de produção não documentada. Alterações de expansão e contração reduzem o acoplamento da implantação: adicione uma coluna ou tabela compatível, implante código que lide com as duas formas, preencha os dados, troque as leituras e só remova a forma antiga em uma release posterior.

Backups só contam depois que uma restauração funciona. Agende uma restauração em um ambiente isolado e verifique fatos no nível da aplicação: usuários conseguem se autenticar, limites entre locatários permanecem intactos, arquivos ainda correspondem a referências no banco, jobs agendados não são executados duas vezes e um fluxo representativo é concluído. Esse trabalho pertence a ambas as stacks. A opção gerenciada muda quem executa a operação de backup, não quem decide se o produto recuperado está correto.

A velocidade do protótipo pode produzir a evidência errada

O primeiro protótipo mede com que rapidez uma stack lida com o caminho que o gerador recebeu no prompt. Ele não mede como o sistema lida com contenção, falhas parciais, evolução de políticas, restaurações ou a investigação de um novo engenheiro seis meses depois.

Node.js e Supabase muitas vezes oferecem um caminho mais curto para um produto convincente orientado a registros. Autenticação, acesso ao banco, armazenamento e comportamento em tempo real ficam disponíveis sem seleção e integração separadas de fornecedores. Um gerador TypeScript tem muitos padrões para imitar. Para um fundador que está validando se as pessoas querem um fluxo, essa velocidade pode pesar mais do que qualquer preocupação teórica sobre portabilidade.

Go e PostgreSQL frequentemente produzem evidências melhores para um produto cuja parte arriscada é o comportamento do backend. Uma API e um worker explícitos permitem testar cedo idempotência, bloqueio, limites de taxa, tentativas de integração e limites de domínio. A interface inicial pode não chegar mais rápido, mas o protótipo exercita a parte com maior chance de falhar.

A recomendação popular de começar com Supabase e reescrever depois é simplista demais. Ela é popular porque muitos produtos nunca precisam ser reescritos e a validação inicial importa. Ela erra quando o protótipo coloca autorização na RLS, fluxo em gatilhos, identidade em claims do provedor, arquivos em convenções de armazenamento e comportamento de eventos em assinaturas em tempo real, enquanto a equipe chama tudo isso de temporário. Uma reescrita então atravessa todos os contratos importantes de uma só vez.

A recomendação oposta, criar agora um serviço Go limpo porque a escala virá, também é fraca. Ela pode gastar tempo escasso em infraestrutura de endpoints, implantação e limites de serviço antes de alguém descobrir se o produto merece tudo isso. Uma arquitetura não usada tem disponibilidade perfeita.

Prototipe o risco, não as telas. Se a política de locatários é difícil, crie regras RLS representativas e ataque-as com testes entre locatários. Se o processamento em segundo plano é difícil, execute workers diante de entrega duplicada, timeout, cancelamento e reinicialização. Se a portabilidade é contratual, restaure o banco e implante a aplicação em um segundo ambiente. Se fundadores sem perfil técnico precisam manter o produto, peça que façam uma alteração real de esquema e fluxo pela interface de geração e depois inspecione o diff resultante.

Modo de planejamento, snapshots e reversão podem tornar a iteração gerada mais segura, mas não transformam uma reversão do banco em uma máquina do tempo. Uma alteração de esquema que exclui ou regrava dados de clientes exige backup e um plano de recuperação futura, mesmo quando o código da aplicação consegue voltar a um snapshot anterior.

Uma matriz de decisão para o sistema após o lançamento

Escolha Go com PostgreSQL quando o comportamento personalizado do servidor for a parte difícil do produto, a equipe souber operar Go, o controle de SQL importar e você quiser componentes de implantação com contratos substituíveis. Escolha Node.js com Supabase quando o produto for principalmente fluxos de dados autenticados, a equipe dominar TypeScript, os serviços integrados eliminarem configuração relevante e a RLS expressar permissões com clareza.

Dê uma nota de um a cinco ao produto real nestes critérios e depois discuta cada nota em que integrantes da equipe diferirem por mais de um ponto:

Não some as colunas sem pensar. Dê peso aos dois ou três critérios que podem inviabilizar o produto. Um fluxo de saúde pode colocar localização dos dados e autorização acima da velocidade de desenvolvimento. Uma ferramenta interna de aprovação pode se importar muito mais com rapidez de entrega e TypeScript conhecido. Um produto de importação de dados pode depender de recuperação de workers e controle de consultas.

Desenhos híbridos são legítimos quando o limite é explícito. Um worker em Go pode processar jobs de longa duração no PostgreSQL do Supabase enquanto uma aplicação web em TypeScript usa Auth e APIs comuns de tabelas. Um serviço de frontend em Node pode chamar uma API Go responsável pelos fluxos transacionais. O híbrido se torna prejudicial quando ambos os lados podem alterar o mesmo estado sem que um seja responsável pelo invariante.

Escreva um registro de arquitetura de uma página antes da geração. Descreva a carga de trabalho, a autoridade de cada invariante, o limite da transação, o modelo de job assíncrono, a fonte de identidade, a responsabilidade pelos arquivos, o destino de implantação, o método de recuperação e a restrição de portabilidade. Depois, faça o código gerado comprovar essas escolhas. A qualidade do prompt ajuda, mas um registro de arquitetura impede que o gerador decida silenciosamente as partes difíceis usando qualquer exemplo que tenha visto com mais frequência.

A decisão da stack está completa quando a equipe consegue explicar uma solicitação que falhou, restaurar o estado do cliente e mudar uma regra de negócio sem adivinhar onde ela está. Escolha o desenho que torna essas três tarefas comuns.