Single Blog

Notification Pattern – Agrupando notificações

Dando continuidade ao assunto “Validações” e Notification Pattern, vamos ver hoje como podemos consolidar as validações de domínio, de comandos, de infraestrutura e o que mais houver em sua aplicação, tendo um retorno único para o cliente.

Onde as falhas podem ocorrer?

Já comentei no post anterior sobre a diferença entre notificações e exceptions, então recomendo a prévia leitura do mesmo.

Bom, podemos notar que temos diferentes cenários em nossas aplicações que podemos trabalhar com Notification Pattern (Também explicado no post anterior), e sendo assim, temos um problema.

Se toda entidade possuir sua lista de notificações, posteriormente, teremos que verificar quais estão válidas ou não.

Além disso, o Notification Pattern não se aplica necessariamente a apenas entidades.

E quando queremos validar algo nos Handlers, Commands, ou até mesmo em outra camada, como a de Infraestrutura?

Primeiramente, devemos tomar um extremo cuidado sobre onde e como validar nossas regras, OK? Não é por que temos a possibilidade de ter uma notificação na infraestrutura que vamos sair validando o estoque de um produto lá!

Pois bem, no cenário onde fiz esta implementação, eu tenho os seguintes contextos que podem ter notificações:

  • Entidades
  • ValueObjects
  • Commands
  • CommandHandlers

Notification Pattern – Consolidando as notificações

Após a minha implementação no post anterior, recebi alguns E-mails me perguntando como poderia consolidar as notificações, afinal, em um cenário mais extenso, são tantas entidades e VOs que validar um a um seria um risco enorme.

Existem várias formas de realizar esta ação. Por exemplo, no caso do Room Booking (Aplicação que desenvolvi com o Yan Justino), utilizamos Dependency Injection para criar um escopo global de validações, que serviu muito bem para aquele cenário extenso e monolítico.

Neste novo cenário, os contextos estão menores e bem divididos, então o primeiro passo para mim era evitar o uso de DI para algo tão simples quanto as notificações que o Notification Pattern prega.

A resposta foi criar uma classe estática, que eu chamei de Runtime (Baseado no framework SimpleCQRS), onde inicio ela no meu Controller base, e finalizo ela lá também (Afinal,. ela não tem um construtor).

Como podemos notar, apenas movi as notificações e os métodos para trabalhar com elas para esta classe!

Deste modo, olha que lindo fica meu BaseController:

Conseguimos validar a requisição apenas chamando o Runtime.IsValid, e assim tomando a decisão aqui.

Nosso CustomerController também ficou mais enxuto, já que quase não precisa tomar decisões <3

Mais refatoração

Ainda no post anterior, fizemos uma implementação para adicionar notificações as entidades, VOs e comandos, utilizando a herança de uma classe abstrata e chamando o método AddNotification da mesma, que caso houvesse erro, adicionava uma nova notificação.

Agora que temos um Runtime para todo o contexto, não precisamos mais disso. Vamos então alterar o nosso Assertion Concern para adicionar notificações direto ao Runtime, ao invés de retornar a notificação (Ou nulo).

Esta classe é um pouco extensa mesmo, mas contém as validações como comentado no post anterior.

Pois bem, agora temos um parâmetro a mais, representando a entidade, VO, Command ou o quer que seja. Precisamos deste parâmetro para caso queiramos saber se determinado item é válido ou não, chamando o método IsValid(Guid entity) do Runtime.

Neste caso, utilizei um Guid, mas poderia ser uma String, um Enum. Como quase todos meus itens são identificados por Guids, resolvi manter o padrão.

Refatorado o Assert, é hora de alterar as validações nos objetos. Como exemplo, separei o Name (Value Object).

Aqui fiz duas modificações significantes. Primeiramente, exclui o método IsValid, já que posso saber se o nome é valido apenas chamando Runtime.IsValid(name.Id) (Lindo né), e também movi as validações iniciais (Para registrar um nome) para dentro do construtor, assim não há risco de esquecer de validar.

Conclusão

Já são 04:30 da manhã, eu ia apenas dar andamento no projeto, mas resolvi refatorar estes itens, que tomaram um bom tempo, mas ficaram muito legais.

Neste novo formato, podemos validar em qualquer lugar (Veja este exemplo abaixo, onde podemos validar se um cliente com o E-mail informado já existe, direto no CommandHandler), e além disso, melhoramos o BaseController/Controllers e melhoramos a legibilidade do código em nossas entidades e VOs.

E aí, o que acharam?

Curso Modern Web Apps

Gostou deste post e quer aprender mais sobre DDD, CQRS, arquitetura, APIs, além de Frontend com Angular 2 e Mobile com Ionic, se inscreve no meu próximo curso.

Vai ser dia 28/01, online e ao vivo, onde você pode perguntar via Chat ou Voz, recebe certificado de conclusão, e ainda ganha acesso aos outros 86 cursos do site.

O Modern Web Apps é um curso completo, onde você vai aprender a criar uma aplicação do começo ao fim. O curso se baseia em um caso real, de uma aplicação de pedidos e delivery de comida saudável, o Salva Dieta.

INSCREVA-SE JÁ — VAGAS LIMITADAS

https://www.sympla.com.br/modern-web-apps__88318

Comments (1)

Post a Comment

© Copyright - balta.io