André, parabéns pelo conteúdo! Tira uma dúvida? Quando você trás o cenário da arquitetura hexagonal, pontuando sobre notificação me surgiu uma dúvida sobre o design da arquiteta! Supondo que minha notificação depende de configurações proveniente de um bando de dados, como eu poderia tratar isso? Ex: Um adaptador de notificação consumindo um adaptador de persistência?
8 หลายเดือนก่อน +1
Obrigado! Não sei se entendi bem sua pergunta, mas vamos lá! Interpretando aqui o que você trouxe, parece que o acesso para construção do conteúdo da notificação ou até mesmo a decisão se irá gerar uma notificação é uma regra de negocio sua, logo, essa parte não deve ficar no adaptador de notificação e sim nas camadas mais internas do sistema (podendo fazer uso do banco de dados por intermédio de adaptadores). Após ter a notificação construída, aí sim iria chamar lançar uma notificação por intermédio de um adaptador (se necessário).
@ entendi e muito obrigado!! supondo que as configuracoes para configurar e disparar a notificado via SMS, por exemplo: endpoint e credenciais que possivelmente estejam em um database.. isso faria sentido ser um adapter chamando outra adapter?
8 หลายเดือนก่อน +1
@@2010paulin Não, ter um adaptador chamando outro iria gerar um acoplamento que não queremos. Você deve passar essas informações necessárias para o adaptador, através do uso de uma abstração (interface) que terá sua implementação (adaptador) injetada. Exemplo: 1) Seu Core obtém o que é necessário do BD, como configs, etc. 2) Seu Core (pode ser um use case ou algo do gênero, depende como tá sua aplicação) verifica qual o tipo da notificação e chama a abstração correspondente, passando os dados necessários ("ISMSNotifier" por exemplo) 3) Seu adaptador ("TwilioSMSNotifier" por exemplo) que implementa ISMSNotifier utiliza os dados que recebeu e faz a integração específica com o sistema de notificação de SMS escolhido.
André, parabéns pelo conteúdo! Tira uma dúvida?
Quando você trás o cenário da arquitetura hexagonal, pontuando sobre notificação me surgiu uma dúvida sobre o design da arquiteta! Supondo que minha notificação depende de configurações proveniente de um bando de dados, como eu poderia tratar isso? Ex: Um adaptador de notificação consumindo um adaptador de persistência?
Obrigado! Não sei se entendi bem sua pergunta, mas vamos lá!
Interpretando aqui o que você trouxe, parece que o acesso para construção do conteúdo da notificação ou até mesmo a decisão se irá gerar uma notificação é uma regra de negocio sua, logo, essa parte não deve ficar no adaptador de notificação e sim nas camadas mais internas do sistema (podendo fazer uso do banco de dados por intermédio de adaptadores). Após ter a notificação construída, aí sim iria chamar lançar uma notificação por intermédio de um adaptador (se necessário).
@ entendi e muito obrigado!!
supondo que as configuracoes para configurar e disparar a notificado via SMS, por exemplo: endpoint e credenciais que possivelmente estejam em um database.. isso faria sentido ser um adapter chamando outra adapter?
@@2010paulin Não, ter um adaptador chamando outro iria gerar um acoplamento que não queremos.
Você deve passar essas informações necessárias para o adaptador, através do uso de uma abstração (interface) que terá sua implementação (adaptador) injetada.
Exemplo:
1) Seu Core obtém o que é necessário do BD, como configs, etc.
2) Seu Core (pode ser um use case ou algo do gênero, depende como tá sua aplicação) verifica qual o tipo da notificação e chama a abstração correspondente, passando os dados necessários ("ISMSNotifier" por exemplo)
3) Seu adaptador ("TwilioSMSNotifier" por exemplo) que implementa ISMSNotifier utiliza os dados que recebeu e faz a integração específica com o sistema de notificação de SMS escolhido.