Suíte PMQ

Bibliotecas públicas em .NET que eu escrevo e mantenho. É a parte do meu trabalho que qualquer pessoa pode ler hoje, sem acordo de confidencialidade.

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

De onde vieram

Os mesmos problemas aparecem em todo serviço .NET que eu escrevo: como a regra de negócio reclama, como o caso de uso é despachado, como o erro chega ao cliente, quem é o chamador.

Resolvi cada um deles algumas vezes antes de escrever estes pacotes, e é daí que eles vêm. Não de um recorte do que já existia, mas de opinião formada sobre o que funciona, escrita do zero. São melhores que as minhas primeiras versões, e o motivo é simples: quem já errou numa implementação consegue tirar mais da seguinte.

A tese

Não são 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 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 no PMQ.Notifications, de que nada obriga o chamador a verificar, acabou resolvida estruturalmente: o pipeline verifica por todo mundo.

Decisões que eu defendo

Generalizar 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. Cada pacote daqui veio de um problema que eu já tinha resolvido mais de uma vez.

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 dela.

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.

Por que isto importa no portfólio

Estes 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.