Suíte PMQ

Cinco bibliotecas públicas em .NET, extraídas de sistemas que já rodavam em produção e generalizadas. É a parte do meu trabalho que qualquer pessoa pode ler hoje, sem acordo de confidencialidade.

Pacote	Downloads	O que resolve
PMQ.Notifications	1.432	regra de negócio violada como dado, não como exceção
PMQ.Mediator	637	mediator com pipeline de comportamento e validação
PMQ.ErrorHandling	748	resposta de erro padronizada em ASP.NET Core, RFC 9457
PMQ.Identity	484	autenticação agnóstica de provedor, OIDC ou JWT próprio
PMQ.Domain	602	blocos de DDD: entidade, agregado, objeto de valor, evento

De onde vieram

Mantendo dezenas de serviços .NET no mesmo parque, o mesmo conjunto de problemas reaparecia em cada um: como a regra de negócio reclama, como o caso de uso é despachado, como o erro chega ao cliente, quem é o chamador. Cada serviço resolvia do seu jeito, e nenhum jeito era igual ao outro.

Duplicação entre serviços não dói de imediato. Dói na hora de corrigir: um comportamento errado de tratamento de erro precisava ser corrigido em dezenas de lugares, cada um com uma variação. Já existiam bibliotecas compartilhadas internamente, mas amarradas a dependências da empresa e impossíveis de reaproveitar fora dela. Extraí as cinco abstrações, limpei as dependências internas e publiquei.

A tese

Não são cinco exercícios soltos. Juntos, são os blocos de uma Clean Architecture:

PMQ.Domain          →  o domínio: entidade, agregado, objeto de valor, evento
PMQ.Notifications   →  como a regra reclama, sem lançar exceção
PMQ.Mediator        →  como o caso de uso é despachado, com validação no caminho
PMQ.ErrorHandling   →  como o erro chega ao cliente HTTP
PMQ.Identity        →  quem é o chamador, independente de quem emite o token

Como as cinco peças se encaixam

O encaixe é a tese. A notificação que o domínio acumula é a mesma que o pipeline do mediator consulta antes de executar, e a mesma que o tratador de erro converte em resposta HTTP. Foi assim que a fraqueza aceita na ADR 2 — Notificação acumulada em vez de exceção, de que nada obriga o chamador a verificar, acabou resolvida estruturalmente: o pipeline verifica por todo mundo.

Decisões que eu defendo

Extrair depois do terceiro caso. Abstração criada na expectativa de reúso quase sempre está errada. Só o terceiro uso revela o que é essencial e o que era acidente do primeiro. Os cinco pacotes nasceram de código que já rodava em produção em mais de um serviço.

Notificação em vez de exceção. Regra de negócio violada é resultado previsto, não falha do programa. É a decisão que amarra a suíte, e o pacote que a implementa é o mais baixado dos cinco.

Padrão de mercado onde ele existe. O tratamento de erro segue RFC 9457 em vez de formato próprio. Inventar formato é custo para quem consome.

O caminho de uma abstração

O mediator interno da empresa nasceu para desacoplar módulos num serviço corporativo. Funcionou, foi adotado por outros sistemas, e a versão generalizada e limpa das dependências internas virou PMQ.Mediator. É o padrão que eu repito: resolver o problema concreto primeiro e extrair depois.

Por que isto importa no portfólio

O código corporativo é maior em volume e em complexidade, e ninguém de fora pode lê-lo. Estes cinco pacotes são verificáveis: o código está aberto, o histórico está público, e o número de downloads não depende da minha palavra.

Ver também

Modelagem de domínio, DDD e CQRS · Documentação e mapeamento de sistemas