Facilities - O Que Faz

O que são facilities no contexto de desenvolvimento de software

O termo facilities aparece em vários lugares da indústria e gera confusão porque cada framework usa o conceito de um jeito diferente. A essência é sempre a mesma: um facility é um bloco de funcionalidade que estende um sistema base sem modificar o core dele. Em vez de esvaziar seu código de dependência ou adicionar lógica ao motor principal, você empacota recursos adicionais em módulos isolados e os registra onde quiser. No ecossistema .NET, o exemplo mais conhecido é o Castle Windsor Facility. Ele funciona como um plugin para o container de inversão de dependência. Você cria uma classe que herda de IWindsorFacility e sobreescreve o método Init(), registrando handlers, components e configurações personalizadas. O Windsor carrega esses facilities automaticamente quando você invoca Install() durante a bootstrap da aplicação.

Facilities - o que faz na prática

Na prática, facilities servem para encapsular responsabilidades transversais que se repetem em múltiplos projetos. Logging, caching, filas de mensagem, integração com terceiros, validação — tudo isso vira facility quando você precisa reaproveitar o mesmo comportamento em cinco aplicações diferentes sem copiar e colar código. O grande ganho não é técnico, é organizacional. Uma equipe mantém o facility centralizado. Quando surge uma mudança no serviço de mensageria, você atualiza um lugar e os consumers não precisam ser recompilados ou refeitos. Eu construí um facility de retry com backoff exponencial para o Windsor que já usei em pelo menos quatro sistemas diferentes. O problema foi que o primeiro deployment enfrentou uma exceção silenciosa quando o serviço de mensageria retornava status 503 intermitentemente. O facility entrava em loop infinito porque o handler de exceção não estava captando o tipo errado de exception. A correção foi adicionar um filtro de status code HTTP antes de tratar a exceção como retryável. Isso reduziu os timeouts de cerca de 12 minutos para aproximadamente 45 segundos em condições adversas.

Como implementar um facility básico passo a passo

Comece definindo qual sub-sistema você quer estender. No caso do Castle Windsor, instale o pacote NuGet e crie uma classe que herde de BaseFacility. Implemente Init() para registrar seus componentes. O método Destroy() serve para limpeza quando o container é descartado.

public class MinhaFacility : BaseFacility
{
    public override void Init()
    {
        Component.For<IServicoExterno>()
            .ImplementedBy<ServicoExternoImpl>()
            .LifestyleSingleton();
    }

    public override void Destroy()
    {
        // fechamento de conexões, dispose de recursos
    }
}

Depois, registre durante a inicialização do container. Use Install(new MinhaFacility()) dentro do método BuildKernel(). Esse é o padrão esperado e qualquer desenvolvedor que assumir o código vai entender imediatamente o que está acontecendo. Um detalhe que muita gente erra: facilities não devem conter estado mutável compartilhado entre instâncias. Se seu facility guarda conexões ou caches globais, eles persistem pelo ciclo de vida do container. Testes unitários ficam imprevisíveis quando isso acontece. Sempre injete dependências de forma explícita e use lifecycle management adequado.

Pegadinhas comuns e onde o modelo quebra

O primeiro erro frequente é confundir facility com middleware. Facility opera no nível do container de dependências, middleware opera no pipeline de requisições. Eles resolver problemas diferentes. Se você colocar lógica de negócio dentro de um facility, está usando a ferramenta errada. Separe claramente: facility gerencia registrations e infra, middleware gerencia fluxo de request/response. O segundo erro é esquecer que facilities executam na ordem de registro. Se FacilityA depende de algo que FacilityB registra, e você instala B depois de A, o container vai reclamar na bootstrap. A solução é ordenar intencionalmente ou usar deferred resolution quando necessário. Eu perdi cerca de duas horas num sábado debugando isso em um projeto legado porque alguém havia embaralhado a ordem de install sem dokumentar o motivo.

Há também o problema de versionamento. Quando seu facility depende de uma versão específica de uma biblioteca externa e outra aplicação consome uma versão diferente, o resolve de dependência entra em conflito. O workaround que eu uso é isolar todas as dependências pesadas dentro do próprio facility via private assembly resolve, mas isso limita a capacidade de upgrade. Se sua equipe cresce e o facility precisa ser adotado por mais times, considere transformar o facility em um pacote NuGet separado com versionamento semântico claro.

Quando facilities não são a resposta certa

Não force facilities onde um simples componente registrado diretamente já resolve. A complexidade extra de criar uma hierarquia de facility não vale a pena para funcionalidades que aparecem apenas em um projeto. O overhead de manutenção, teste e documentação rapidamente supera qualquer benefício de abstração. Outro cenário onde facilities falham é em microsserviços com deploy independente. Cada serviço deve ser autocontido. Empacotar lógica de infra em facilities compartilhados cria acoplamento silencioso entre serviços. Nesses casos, uma biblioteca comum com helpers é mais transparente e mais fácil de depurar do que um facility escondido dentro do container.

Se o seu objetivo é apenas centralizar configurações ou constantes, um arquivo de configuração ou um serviço de options já faz o trabalho. Facilities existem para extensibilidade de container, não para organização de dados.