Modelagem de domínio, DDD e CQRS
Colocar a regra no domínio, não no controller nem na procedure. Entidade que protege o próprio invariante, transição de estado explícita, e comando separado de consulta.
A prova mais direta é pública
O código corporativo ninguém de fora pode ler, então o que sustenta esta competência são os pacotes que eu publiquei. PMQ.Domain tem entidade com igualdade por identidade, raiz de agregado, objeto de valor e evento de domínio. PMQ.Mediator tem pipeline de comportamento e integração de validação. Estão no NuGet, com 1.550 downloads no mais baixado da suíte, e o código está aberto.
Validação declarativa é padrão no que eu escrevo: a regra fica no tipo, e não espalhada pelo serviço que o usa.
O que eu faço
- Modelar agregado com invariante protegido no próprio tipo, em vez de validar no serviço
- Implementar transição de estado como regra ordenada e explícita, onde a ordem das cláusulas é a precedência
- Separar comando de consulta, com handler por caso de uso e pipeline de validação antes da execução
- Usar notification pattern: regra de negócio violada devolve notificação acumulada, não exceção
- Emitir evento de domínio no ponto de mudança e reagir fora do fluxo principal
- Escrever objeto de valor para o que o sistema trata como conceito, não como string
A decisão que eu defendo
Validação como dado em vez de exceção. Exceção interrompe o fluxo e devolve o primeiro erro, e a operação real quer devolver todos os problemas de uma vez. Regra de negócio quebrada é resultado esperado, não falha do programa. Foi por isso que PMQ.Notifications existe, e é a decisão que amarra a suíte inteira.
Onde apliquei
Pagamentos e antifraude · Experiência · Monitoramento industrial
O que eu ainda não fiz
Não apliquei event sourcing nem CQRS com base de leitura separada fisicamente. O meu CQRS é separação de responsabilidade dentro do mesmo banco, o que resolve o problema de organização e não o de escala de leitura.