Organizar um projeto grande
O que muda quando o projeto passa de duzentos arquivos — e as quatro decisões que decidem se ele continua navegável.
Num arquivo de quarenta linhas, qualquer organização funciona. O que segue é o que passa a importar quando a maioria das chamadas atravessa módulo.
Por assunto, e não por tipo#
| Por tipo (não) | Por assunto (sim) |
|---|---|
modelos/, servicos/, rotas/ | pedidos/, clientes/, estoque/ |
| mudar uma regra toca três pastas | mudar uma regra toca uma pasta |
| a fronteira do domínio não aparece | a pasta é a fronteira |
modelos/ com quarenta arquivos | cada pasta cabe na tela |
text
src/
pedidos/
modelo.df record Pedido, e as regras dele
repositorio.df como ele e guardado
rotas.df como ele e exposto
pedidos_test.df
clientes/
...
compartilhado/
tipos.df o que MESMO e de todosO ciclo de import é erro, e não estilo#
Ele estourava só em execução, no primeiro adopt, e o check passava limpo num projeto que não sobe. Hoje o check acusa — e a mensagem mostra a cadeia inteira, porque um ciclo de quatro arquivos é impossível de quebrar sem saber por onde ele passa.
bash
dataforge check src/ # acusa o ciclo, com a cadeia
dataforge deps # o grafo de imports
dataforge deps --ciclos # so os ciclosO que medir num projeto grande#
| Comando | O que ele responde |
|---|---|
dataforge stats | as ações e blueprints, o arquivo e a ação mais longos |
dataforge oop | acoplamento e coesão; os cheiros com o princípio SOLID |
dataforge deps | quem depende de quem, e os ciclos |
dataforge big-o | a classe de complexidade de cada ação |
dataforge test --cobertura | o que nenhum teste toca — e um arquivo sem teste aparece com 0%, em vez de sumir |
Continue em O cache de árvores e Diagnóstico.