Do primeiro Inject a uma arquitetura modular com Zenject

Dependency Injection começou, para mim, como uma forma de retirar dependências escondidas dos componentes de Unity. Com o tempo, a pergunta deixou de ser “como injetar este objeto?” e passou a ser “onde este sistema nasce, quem pode usá-lo e quando ele deixa de existir?”

Essa mudança pode ser acompanhada por uma sequência de projetos. Ela não é uma comparação de qualidade entre jogos, nem uma afirmação de que toda etapa foi planejada desde o início. É uma cronologia de aprendizado: experimentos pequenos revelaram limites que projetos maiores obrigaram a tornar explícitos.

Como ler a evidência

Cada estágio abaixo usa uma origem diferente:

• confirmado no código e no Git: a estrutura atual e sua passagem pelo histórico local puderam ser inspecionadas;
• relato do autor: a sequência é conhecida, mas o repositório ainda precisa ser recuperado ou catalogado;
• proposta futura: descreve uma direção, não uma ferramenta já publicada.

Essa separação importa. Memória orienta investigação, mas não substitui um artefato verificável.

1. Descoberta: pesquisa antes do padrão

O primeiro contato mais consciente com Zenject veio durante o período ligado a Demerara, depois de pesquisa sobre arquitetura em Unity e de uma apresentação técnica associada ao trabalho da Niantic em Pokémon GO. Este estágio permanece como relato do autor: ele explica a origem da direção, não comprova uma implementação de produção específica.

O aprendizado inicial foi simples e importante: um componente não deveria descobrir sozinho tudo de que precisa. Tornar dependências visíveis melhora substituição, depuração e teste — mas isso só funciona quando existe um lugar claro responsável por compor o conjunto.

2. Primeiro recorte lembrado: Stylized Action Prototype

O Stylized Action Prototype é a primeira implementação lembrada dessa abordagem. O escopo era de protótipo: exploração, câmeras de área e combate por cartas ainda estavam descobrindo a própria forma. Dependency Injection entrou como ferramenta de organização, não como uma camada universal pronta.

Esse estágio ensinou uma diferença que continuaria importante: usar um container não é o mesmo que desenhar uma arquitetura de composição. Um protótipo pode se beneficiar de dependências substituíveis sem precisar antecipar todos os módulos de um produto futuro.

O uso de Zenject neste recorte permanece classificado como relato do autor até que o estado correspondente do repositório seja recuperado e associado a uma build.

3. Integração aplicada: protótipo educacional de matemática

Em um protótipo educacional no qual o jogador respondia questões enquanto um pássaro caía, a arquitetura passou a conviver com chamadas de API e implementação de endpoints. A injeção de dependências ajudava a separar integração, regras do jogo e apresentação — uma necessidade mais concreta do que no experimento anterior.

O nome definitivo, o período exato e o repositório deste projeto ainda precisam ser catalogados. Por isso, este estágio é publicado como relato do autor com recuperação pendente, sem transformar detalhes lembrados em prova técnica.

4. DATA2073: composição na escala do produto

Em DATA2073, entre 2025 e 2026, a abordagem ganhou escala de produto. A inspeção local confirma Zenject atravessando sistemas de tutorial, inventário, deck, missões, recompensas, loja, temporadas, leaderboard e modos de jogo. Também aparecem composições distintas para responsabilidades de cliente, servidor e partes compartilhadas.

O salto não está na quantidade de pontos de injeção. Está na criação de uma linguagem comum para montar features:

• installers delimitam o que cada módulo oferece;
• controllers e serviços são resolvidos por contrato;
• sinais comunicam transições sem acoplamento direto entre telas e regras;
• factories preservam a construção pelo container;
• contextos de cena e de estado ajudam a selecionar o escopo correto;
• módulos de cliente e servidor podem compor implementações diferentes da mesma capacidade.

O projeto também registra helpers para objetos criados fora do fluxo normal do container e uma instalação recursiva de contratos encontrados em uma hierarquia. Essas soluções reduziram trabalho manual em um produto extenso, mas revelaram o próximo risco: quanto mais automática a descoberta, mais importante se torna saber qual escopo possui a dependência e qual lifecycle é responsável por removê-la.

O objetivo declarado era automatizar composição sem criar custo relevante em runtime. A estrutura confirma a intenção arquitetural; ela não substitui um benchmark. Performance continua sendo uma hipótese que precisa de profiling reproduzível.

5. Triple Z Stealth: limites explícitos e ciclo de runtime

Em Triple Z Stealth, em 2026, os aprendizados anteriores aparecem reorganizados em uma camada de infraestrutura mais explícita. O projeto preserva helpers e factories equivalentes, mas torna a composição da simulação uma responsabilidade visível.

Cliente, servidor, host e partes compartilhadas possuem caminhos próprios de instalação. Sistemas de autoridade ficam separados dos sistemas de previsão e apresentação. Entidades como jogador, sessão, projétil e objetos interativos recebem escopos de composição adequados ao seu ciclo de vida. A infraestrutura de runtime consegue instalar, consultar, habilitar, desabilitar e desmontar conjuntos de sistemas sem fazer a regra depender de uma única forma de conexão.

Há ainda composições específicas para teste. Em vez de obrigar um teste a inicializar o jogo inteiro, ele pode construir apenas o container e os contratos necessários para o cenário. Essa é uma mudança qualitativa: a arquitetura deixa de apenas fornecer objetos e passa a definir fronteiras executáveis entre ambientes.

O histórico local confirma a base de injeção no início de 2026 e a consolidação das composições de simulação nos meses seguintes. Como o case é anonimizado, esta leitura publica somente princípios arquiteturais; regras, endpoints e código proprietários permanecem fora do portfólio.

A evolução em uma linha

O que merece virar ferramenta

A próxima etapa não deveria ser copiar helpers de um jogo para outro. Uma biblioteca reutilizável precisa extrair somente contratos que sobreviveram a contextos diferentes:

1. composition roots legíveis para aplicação, cena, entidade e teste;
2. instalação e desmontagem simétricas;
3. separação entre composição compartilhada, cliente, servidor e host;
4. factories que preservem o container sem esconder criação;
5. diagnóstico de bindings, escopos e duplicidade;
6. exemplos mínimos e testes que não dependam de um jogo específico;
7. profiling comparável antes de qualquer promessa de performance;
8. pacote versionado, documentação e estratégia de migração.

Essa ferramenta ainda não está publicada. O trabalho atual é identificar o núcleo que pode ser generalizado sem levar consigo nomes, regras ou dependências proprietárias dos projetos.

O insight principal

Dependency Injection amadureceu quando deixou de ser uma conveniência aplicada em componentes e passou a representar o desenho operacional do software. No primeiro estágio, ela respondia “quem fornece este objeto?”. Em DATA2073, passou a responder “qual módulo oferece esta capacidade?”. Em Triple Z Stealth, também precisa responder “em qual autoridade, ambiente e momento este sistema pode existir?”.

A melhor medida de evolução, portanto, não é o número de atributos Inject. É a redução de ambiguidade: menos dependências descobertas por acaso, menos inicializações duplicadas, menos regras misturadas entre cliente e servidor e testes capazes de montar apenas o mundo que precisam observar.