Como integrar com diversos sistemas sem "SUJAR" sua aplicação?

Olá pessoal sejam bem-vindos a mais um vídeo aqui no canal e hoje o nosso papo é sobre integrações um tópico um pouco mais específico que seria como será que a gente consegue integrar diversos sistemas sem sujar as nossas aplicações né aplicações eu digo aqui num contexto geral né porque a gente sabe que integrações sempre acontecem entre sistemas E aí vamos abordar um pouquinho sobre como evitar de uma integração externa de um sistema ou de n sistemas interferir tanto vamos dizer poluir tanto o seu sistema principal o Core ali do seu sistema mas antes de começar

o vídeo aqui não se esqueça de deixar um like de se inscrever no canal de compartilhar os vídeos se você tá gostando desse formato deixe seu feedback aqui também nos comentários ou se você prefere lives vai conversando comigo através dos comentários para eu sentir o conteúdo que vocês querem sugestões de conteúdo também e não se esqueçam de entrar na nossa comunidade do discord os links estão na descrição Mas vamos lá para começar o vídeo aqui eh já que a gente vai falar de integrações um ponto importante é conceituar aqui né ou alinhar Por que integrar

né Por que que eu preciso integrar meu sistema com outros sistemas externos eu sei que não são todos os tipos de sistemas que necessitam de integração com com outros softwares né Isso é óbvio mas aí sistemas Line of Business que trabalham com um setor específico eh a contabilidade administração eh ou de nichos específicos muitas vezes eles precisam se integrar com outros sistemas sejam eles erps de empresas seja eles sistemas outros sistemas administrativos eh enfim n tipos de sistemas até sistemas do tipo Gates de pagamento e-commerces enfim né Tem uma variedade muito grande aí de sistemas

que podem ser integrados Mas por que integrar né Essa necessidade vende eh é você necessitar vender o teu software né entrar numa empresa ou já estar dentro de uma empresa oferecendo o teu serviço teu software por algum motivo eh e na empresa para cobrir todos os os setores todas as tarefas que precisam ser feitas da empresa muitas vezes um sistema só não dá conta né ou não faz tudo nós temos os rps aí no mercado que procuram atender várias partes da empresa né para tentar unificar todas as tarefas em uma aplicação só que pode ser

modularizada enfim mas mesmo assim né nem elas conseguem eh muitas vezes abranger todas as necessidades E aí o que que acontece surge a necessidade de ter vários sistemas da empresa e como é ruim ter vários sistemas que não se conversam então eh recorrentemente tem a necessidade de você ah preciso puxar a informação do cadastro dos usuários e preciso puxar informação lá do chão de fábrica ou informação fiscal informação contábil informação de n tipos e aí existem as necessidades de integração então principal coisa é trazer mais valor para aquela empresa tentando dar uma experiência né de

negócio unificada por mais que oos sistemas não sejam unificados isso se faz através de integrações né E você como provedor como desenvolvedor como empreendedor enfim eh que tem o seu sistema rodando você tem que avaliar quais tipos de integrações realmente eh entrega um valor pro seu produto né não é porque que você tem n sistemas aí no mercado que você vai sair integrando com todos né mas você tem que fazer uma análise de mercado ali com o seu Timo de produtos e ver o que faz sentido ah ok eu tenho um sistema aqui meu eh

que eu preciso fazer uma integração com o sistema comercial que é amplamente utilizado no mercado geralmente o perfil dos meus clientes utilizam esse outro software então é um diferencial competitivo o meu software que é nichado muitas vezes se integrar com esse sistema comercial e aí entregar pro pro cliente ali eh mais valor né Essa Experiência unificada então integração sim tem muito valor desde que bem pensado bem eh vamos dizer assim eh Projetada para que a tenda entregue valor pro cliente e não seja mais apenas um adicional que que não não tem valor Beleza então alinhados

aqui para que que serve integração acho que todo mundo concorda né Vamos lá falar desse termo que eu trouxe a no título do vídeo é sujar aplicação Então por que que integrações sujaram ou sujam sua aplicação né primeira coisa que é integrações podem sujar a sua aplicação se você estiver preocup opado com boas práticas Clean code e ter um código bem escrito bem separado com boa manutenção Então depende do ponto de vista esse esse é o ponto que eu quero chegar aqui se você não tem um compromisso com E essas boas práticas Pode ser que

fique imperceptível essa sujeira que eu quero me referir para você então talvez você codifique lá de forma Tudo unificada o Core do seu sistema todas as rotinas as funcionalidades do teu sistema e a integração toda no mesmo lugar misturada as lógicas de negócio com as funcionalidades que são específicas do teu sistema aí vem integração código ali no meio todo misturado e se você não tivesse olhar de boas práticas ou não sentir na pele muitas vezes a os problemas de misturar isso você vai achar que tá ok e não vai sentir essa sujeira tá então primeira

coisa aqui que é uma questão de percepção o segundo ponto é que por que que aplicações podem sujar a sua aplicação é que a integração em sua maioria e quando a gente fala principalmente aí de integrações com sistemas maiores né e mas integrações como um todo já vale também o exemplo aqui elas são elas TM suas peculiaridades né então de certa forma elas são com elas T sua complexidade intrínseca tanto na forma de comunicação com o outro sistema quanto no formato que você tem que falar então por exemplo você tem seu sistema tem o sistema

que eu vou chamar de sistema a aqui e você tem o sistema B certo esse sistema B que você precisa se comunicar Ah ele ele tá exposto através de uma ap rest ele fala Jone né o formato ali a troca de informações é via Jon a autenticação é do tipo x Então você já tem pré-requisitos se já tem características que você precisa se adequar no seu sistema a para conseguir conversar com o sistema B certo mas nem sempre o sistema B ele é um formato Tão vamos dizer assim moderno de mercado ou que é o

mais conhecido hoje ele pode ser uma aplicação que se integra via um um web Service soap fala XML autenticação básica Enfim pode ser uma aplicação que se integra via arquivo por não você tem que colocar o arquivo numa pasta né E aquela aplicação vem e pega às vezes é uma aplicação mais antiga ou a integração que existe já te obriga a fazer via arquivo Então quando você fala de integrações você fala de eh ter que ceder né você tem que ceder um pouco eh um lado tem que ceder para conseguir se comunicar se o sistema

que que vai se integrar com o seu talvez ele tenha que ceder mais né porque a decisão foi de ele vir até o seu sistema E aí você pode padronizar a tua entrada numa forma que você queira Mas talvez você tem que se integrar Então você tem que ceder talvez no formato ou num terceiro caso os dois podem combinar ali um formato um uma uma própria forma de comunicação para ficar no meio do caminho ou até mesmo utilizar um midware no meio do caminho para para fazer essa tradução de formatos essa tradução e da informação

de um tipo para outro tipo então tem vários casos aqui né mas o que eu quero dizer que é integrações já são complexas não necessariamente falam a mesma língua que o seu sistema Então pense você misturar essas línguas aqui né esses eh essas formas de comunicação esses formatos diferentes tudo na mesma aplicação no mesmo Core do seu sistema é uma boa ideia fica aí a reflexão Outro ponto aqui que nos leva a pensar se as integrações surgem Nossa aplicação ou não né quando a gente tem uma funcionalidade no nosso nosso sistema né que o final

dela né o resultado dela ah o desfecho ali precisa se integrar com n sistemas diferentes Então vamos supor que então o sistema é um sistema grande já E aí você tem uma funcionalidade que faz x coisa E aí tem sistemas de mercado aqui conhecidos enfim que podem se integrar com o seu sistema Ah então tem o erp1 o 2 e o 3 ambos T funcionalidades Pareci que se encaixariam no meu então eu poderia fazer o quê criar três integrações para que se o meu cliente tiver o rp1 eu consegi entrar e me integrar a ele

se tiver rp2 e 3 tendo três necessidades de integração de três sistemas diferentes aí eu já estou misturando três códigos de integração que podem conversar de formatos diferentes de formas diferentes de autenticações diferentes mais um questionamento aqui é uma boa ideia eu misturar isso Quando surgir a quarta integração a quinta enfim ficar misturando isso no mesmo código pensa lá na tua rotina de de funcionalidade cheio de if if sistema externo um if sistema externo 2 enfim todo um um macarrão de código ali é uma boa ideia Na minha opinião não na minha opinião suj o

código né então a gente tem técnica para melhorar isso aí mas ainda aqui nos problemas de sujar Nossa aplicação né o próprio própria coisa que eu falei agora a pouco né misturar o código da funcionalidade que primeiro tem a lógica de negócio só da sua aplicação que faz a rotina da sua aplicação E aí a rotina de integração a gente consegue pensar de forma diferente né então a minha funcional ADE faz x e a integração faz uma segunda coisa que é enviar dados ou receber dados enfim né mas são blocos que podem ser separados misturar

esses blocos traz uma legibilidade boa pro teu código para aquele Dev que vai chegar vai dar manutenção vai ter que encontrar um bug né vai ter que mexer recorrentemente naquele código e tendo que Lar ler o código e descartando Ah não isso aqui é sistema um isso aqui é sistema dois externo né 3 4 é nesse cinco aqui que tem o bug talvez se tiver tudo misturado será que uma alteração que você vai fazer umaa integração do sistema 3 né que é o sistema externo 3 que você tá se integrando não pode gerar um bug

de forma muito mais fácil em outras integrações sendo que você não separou nada tá tudo misturado Então você começa aí a ter questões de de eh problema de manutenção bugs e tudo mais e encaixando nesse ponto também você tem a questão de testes né se você não separa nada né a gente nem precisa ir pro campo de integração aqui né até as suas próprias funcionalidades Se você deixar tudo misturado é fácil detestar isso né Será que não é mais fácil você dividir em bloco separar isso em classes projetos diferentes para conseguir testar de forma melhor

né testes de unidade aqui por exemplo então né esse é outro ponto também que deixar tudo misturado complica sua vida na hora de escrever os testes e como Último Ponto se você ainda não tiver convencido que misturar integrações no seu Core do seu projeto sujam a sua aplicação e quando você precisa descontinuar uma ação você decide que o sistema externo um não é não faz mais sentido ter a sua na sua base de código agora você quer limpar quer tirar todas as dependências quer realmente excluir aquele código de integração que estava dentro da do Código

da sua funcionalidade todo misturado o quão difícil vai ser gpar o código e pensando né códigos ali implementações que dizem respeito à integração sendo que você não separou nada então vocês devem ter percebido que o Ponto Central aqui é a sujeira está diretamente ligado com o quanto você deixa as integrações e invadirem o Core a sua funcionalidade e você não se preocupa em separar bem as coisas né isso Não serve só para integrações serve para qualquer coisa que você quer ter flexibilidade de plugar desplugar remover adicionar em termos de funcionalidades no seu código por isso

que tem a separação de responsabilidades né mas aqui fica claro Quais que são os problemas de você ter integrações Ah todas misturadas de qualquer forma sem nenhum tipo de cuidado dentro da sua aplicação Mas vamos lá já falei o que que surja a sua aplicação quando a gente tem integrações entrando ali de forma desordenada e ah invadindo mesmo né o seu código o cor do seu das suas aplicações eh ficando todo eh indistinguível do que é funcionalidade nativa da sua aplicação e o que é integração mas beleza sabendo que a gente tem esse problema quais

são as boas práticas ou estratégias que a gente tem Para não acontecer isso para não sujar nossas aplicações quando a gente quer integrar com sistemas extern sistemas diversos aí né seja uma integração com um sistema só ou seja n integrações Então vou começar aqui falando de alguns pontos algumas boas práticas mostrando na tela alguns exemplos alguns diagramas para que fique mais claro primeiro ponto aqui é a questão da Separação das responsabilidades né então Eh como eu falei no nos outros tópicos né a gente deixar as coisas misturadas as implementações misturadas da nossa funcionalidade Nativa com

as integrações com os detalhes ali da integração por exemplo ah ela fala eh num formato XML eu tenho que mandar via web service soap e ou um rest ou é arquivo enfim né Isso são detalhes de implementação da Integração não tem por estar na nossa regra de negócio do nosso domínio do nosso da nossa funcionalidade ali que que pertence apenas à nossa aplicação da nossa rotina interna então a separação de responsabilidades é muito importante já diria o nosso princípio S do Sid né que traz ã isso como um dos pontos muito fortes e que servem

desde você escrever uma classe eh e aumentando esse escopo para projeto para solução Enfim então a separação de responsabilidade é o primeiro ponto para manter a sua aplicação mais limpa e organiz ada E aí aqui ã tem uma imagem que eu vou mostrar uma sequência de imagens h mais ou menos aumentando a complexidade aqui primeiro um desenho bem mais simples e aí eu vou mostrando alguns eh desenhos de Eh vamos dizer assim de arquitetura de projeto aumentando a sua complexidade aumentando um pouquinho eh e também para diversificar os exemplos aqui e a a ideia de

repetir bastante o que eu vou mostrar é justamente para tentar passar a ideia e ah tentar explicar de diferentes formas na esperança que todos entendam visto que pessoas entendem as coisas de formas diferentes né então eu tentar ser o mais didático possível tá o segundo ponto além da separação de responsabilidades que é um termo aqui mais amplo genérico falando de Sid enfim né é a separação se a gente tem aí uma aplicação nossa separação das integrações em projetos separados se você não consegue por n motivo separar em projetos comece pelo menos com separações eh menores

se você tem uma classe que diz que que que tem o seu método de implementação da sua rotina interna com suas de negócio e vem uma necessidade de fazer uma e integração externa pelo menos não coloque tudo na mesma classe criar crie uma classe só para aquela integração mas o melhor dos mundos ainda é e ir um pouquinho além né ter projetos separados eh e a Enfim pode até ter aplicações ali separadas para lidar com cada tipo de integração e aqui O primeiro exemplo então é Imagine que eu tenho uma aplicação só né aqui pode

ser uma solução só na verdade traduzindo aqui para o mundo do pessoal de dnet eu tenho lá o meu visual Studio ten uma Solution e aqui eu tenho as minhas camadas que são que que são um conjunto de projetos né que são o Core né do meu sistema então tenho a camada de domínio de aplicação e a camada de apresentação por exemplo então aqui um exemplo bem simples né de o domain aqui teria as minhas regras de negócio aplicação e orquestral os casos de uso apresentação aqui seria uma interface gráfica ou até própria uma API

para expor isso mas concentrando mais aqui no domain onde teria o código da nossa funcionalidade certo então Imagine que eu tenho que calcular o posto eh x de alguma de alguma coisa né então todas as regras para calcular esse imposto porque o meu sistema faz isso cálculo de imposto por exemplo estão todas no meu domen estão todas nessa minha camada aqui protegida e que não conhece nenhuma integração toda a rotina eu vou fazer aqui e aí eu tenho a necessidade né surgiu a necessidade de integrar com uma um sistema que precisa consumir O Retorno o

o resultado daquele cálculo de imposto E aí eu tenho Outras aplicações aqui que a gente pode chamar de camadas né que vão consumir aquela informação já pronta né o resultado daquilo e aí a estratégia é o quê eu criar então projetos né camadas de infraestrutura e aqui vamos exemplificar né tecnologia A B e C Imaginem que sejam três e sistemas externos diferentes que eu preciso me integrar então tem o sistema A B e C todos eles têm que consumir daquela mesma rotina de cálculo de imposto eh para dar seguimento algum processo certo então qual que

seria o caminho aqui você blinda a tua a implementação Nativa né a sua funcionalidade e você expõe esse dado através de uma API ou através até do de um service uma interface alguma coisa aqui e sendo que a tua implementação interna não conhece nada dessas integrações esses outros projetos que vão ser eh implementados à parte essas outras camadas elas vão saber se comunicar com o sistema externo converter informação que antes tem um formato específico no teu domé aqui vamos supor que você expõe isso através de um Jon essa sua camada que você vai implementar vai

buscar esse Jon né ou vai bater no service vai pegar um dto específico aqui vai trazer para essa camada aqui você vai fazer a trução da informação no que estava no modelo do seu domínio né vai traduzir essa informação para formato do sistema a e vai se comunicar por exemplo com o sistema a através de rest soap enfim n coisas aqui então percebe que você tirando essa integração de dentro do Core aqui do seu do seu sistema você deixa todos os detalhes que dizem respeito à integração a dentro de um projeto específico no momento que

você precisar fazer uma alteração uma manutenção do sistema na integração do sistema a ah eh Acontece muito integrações né agora eu tinha que mandar tag XML chamada e ICMS que é o imposto né agora mudou agora não é ICMS é ICMS traço alguma coisa ou mess mais uma palavra a alteração que você vai ter que fazer não é no Core do seu projeto é na no mapeador né no no mapeamento vamos dizer assim da linguagem do seu negócio do seu sistema Core para a integração específica não fica muito mais fácil ter isso separado e saber

onde atacar saber onde fazer a manutenção do que vim aqui no sistema Core e caçar onde tá aqui dentro ah então essa separação ela começa a mitigar tudo que eu falei ali de eh dos problemas né No momento que eu quiser descontinuar a integração da tecnologia a eu posso simplesmente matar esse projeto aqui de cima né então H são conceitos de segregação aqui de separação de projetos que fazem com que a gente mitiga esses problemas que eu havia comentado beleza Ponto Central aqui separação de responsabilidades e projeto ou solução né separadas em camadas em projetos

separados e aí como eu falei existem níveis de separação aqui você pode ter uma aplicação só e separar as integrações por classes ou ter ção deixar um conjunto de camadas paraa sua aplicação Core que que nem tá E exemplificado aqui no quadradinho azul e projetos separados para as integrações e também você pode ter e soluções e aí quando eu digo soluções seria apis diferentes executáveis diferentes serviços que rodam independentemente também eh fora da sua Solution então por exemplo seu sistema é esse quadrado aqui né e ele é exposto através de uma API E aí você

dá um add New Solution começa a escrever um projeto que vai ser uma outra api por exemplo ou um worker service alguma coisa do gênero que vai se comunicar com a sua aplicação principal através da rede mesmo tá Ah então ele não precisa estar no mesmo executável no mes estar no mesmo processo de execução da sua aplicação então tem níveis de separação beleza dando outro exemplo aqui essa imagem muitos de vocês podem conhecer já né que é a imagem ali mais conhecida da Clean architecture onde ele traz aqui já traz muito desses desses feitos né

só que aqui a gente tá colocando uma temática em cima integrações né integrações com sistemas externos então percebe aqui que ele tá protegendo a enterprise Business rules que seriam suas entidades seus serviços enfim de domínio nessa camada interna aí ele tem a parte dos casos de uso ele tem os adapters que aqui é uma coisa muito importante o que que são os interface adapters são seus controllers são seus gats são seus presenters e aqui a gente poderia entender controllers como a nossa api por exemplo né Então pense nessa questão deixa até circular aqui nessa questão

aqui ó aqui seriam os limites de uma aplicação tua por exemplo né E você tá expondo o quê para fora aqui você pode est expondo uma API certo e essa parte aqui Azul ela não necessariamente precisa estar na mesma aplicação como eu tava mostrando no outro exemplo olha perceba aqui ó external interfaces né a gente pode encarar isso aqui como ã adaptadores que vão saber falar a linguagem do sistema externo que tá aqui então ele vai fazer o qu esse essa parte external interfaces vai vir aqui vai se comunicar com alguma api do seu sistema

vai traduzir isso vai enviar né é e o caminho contrário também o sistema externo pode vir aqui bater numa pi que foi construída nesse external fa external Services por exemplo vai traduzir do modelo externo para o seu interno e vai chamar o Api direcionando uma requisição para dentro do teu sistema Então pode a gente pode encarar de várias formas essa divisão como eu já havia comentado no exemplo anterior certo assim como pode ser encarado como uma um uma solução só né um executável só Onde por exemplo no exemplo do banco de dados aqui eles trazem

esse exemplo aqui não vou abordar muito isso aqui mas só para para vocês entenderem o conceito né Assim como uma API está segmentada está segregada do Core da sua aplicação um banco de dados também pode tá Por quê Porque a tua aplicação pode ser falar a ou ser integrável ali com diversos tipos de banco de dados Então ele pode saber se integrar com posters com SQL server com Oracle desde que você crie implementações para cada um desses bancos e claro tem estratégias para isso usar o RM enfim tem coisas aí que facilitam mas que são

detalhes de infraestrutura que a o Core da sua aplicação não precisa saber então você se prepara para conseguir segregar essa parte que fala a língua dos bancos de dados eh em outra camada da sua aplicação alguns conhecem aí falando muito de dados como a camada de repositórios né então isso é feito justamente para se tornar um pouco mais agnóstico do banco de dados que você vai se conectar e com integrações é a mesma ideia você vai criando adaptadores que vão falando a língua de cada sistema E aí você eh faz a interface com o Core

do seu projeto né da sua aplicação vamos lá evoluindo aqui nos exemplos né a gente falou de Clean architecture né Eh que era o exemplo anterior e aqui a gente já tem um desenho que eu ainda vou evoluir versões desse desenho porque ele se torna uma arquitetura que o pessoal considera mas não necessariamente é um pouco mais complexa né que é a arquitetura hexagonal ou também conhecida como port And adapters ports and adapters né então aqui o que que nós temos um desenho bem mais simples e depois a gente evolui pro desenho mais complexo mas

que a ideia é o qu é sempre a mesma coisa que eu tô explicando só que colocando alguns detalhes a mais aqui para para diferentes pessoas entendem diferentes formas né então vamos lá nesse caso aqui dessa arquitetura de ports and adapters vou dar um exemplo aqui tá tentando usar um pouquinho do exemplo que eu já dei anteriormente mas nesse domain Model então teria a nossa funcionalidade que faz o cálculo do Imposto e aqui eu vou inverter um pouquinho Eh vamos supor que eu tenho que calcular esse imposto e enviar alguma coisa proativamente para um sistema

externo certo eh então aqui eu vou calcular tudo que eu preciso com as minhas regras de negócio internas certo eh e quando chegar o momento de enviar para um sistema Claro baseado em alguma configuração Ah estou me integrando com o sistema a certo eu não vou chamar diretamente Aquela aquele sistema como que eu faço para separar isso ficar agnóstico eh pelo menos o o Core aqui o domain fica agnóstico de qual sistema eu preciso chamar diretamente Eu uso as minhas portas né que eh aqui eu posso encarar como interfaces que não vão me dar a

implementação e sim o contrato apenas Então esse meu domain moddel aqui que pode ter um serviço que calcula o imposto né ele vai calcular o imposto e vai ter um eh uma rotina para enviar quando eu enviar eu vou chamar essa interface vou falar interface Eh sei lá I external service interface né E aí vou dar um um chamar o método lá enviar ou send por exemplo só que é uma interface não tem implementação então em tese isso aqui não funciona só só que isso é bom por porque meu domain Model ele ficou agnóstico de

saber se é o sistema um sistema do que eu vou enviar né que é o o sistema que precisa receber essa informação e aqui eu tô indo para esse lado aqui né mas pode ser esse lado aqui no caso né mas enfim aqui é só para ter a ideia do que é porta e adapter né depois a separação a gente pode mudar né upstream no caso seria a questão de envio aqui mas enfim o que que acontece Então como que eu faço o vínculo dessa interface com um desses adaptadores E aí vem próximo passo das

boas práticas ou estratégias que eu quero mencionar aqui fazer o vínculo entre uma Face e uma implementação para isso eu tenho injeção de dependência percebe que aqui estou usando um conceito que é a inversão de dependência onde ao invés do meu domain Model depender de uma implementação que é um código que especifica Qual que é a integração eu estou dependendo de uma interface ou seja uma abstração que não conhece nada do que está por trás não conhece a implementação ainda estão tô trocando a a tô invertendo a dependência em vez de depender de uma implementação

estou dependendo de uma abstração E aí como uma abstração não tem código né não tem um um desenrolar ali de execução porque apenas o contrato eu uso a técnica de injeção de dependência para fazer o quê Ok vou escrever uma implementação que seria esse adapter aqui ou esse aqui enfim que vai implementar a interface que é o contrato e aí ela vai obedecer obviamente o contrato tendo o mesmo método os mesmos parâmetros e tendo toda uma implementação dizendo como que eu converto esses dados como que eu eh agrupo esses dados como que eu envio esses

dados pro sistema externo Enfim então a injeção de dependência ela faz com que uma implementação né possa ser injetada numa abstração através de um contêiner de gestão de dependência ali então tem algumas estratégias né Eh que que eu que eu posso utilizar que aí em tempo de execução quando meu sistema rodar eu faço essas injeções de dependência né configuro elas no momento do runtime essa implementação vai se vestir vamos dizer assim de interface e aí ela começa a ter esse vínculo dessa interface com essa implementação e o meu domain Model chamando essa abstração aqui ele

automaticamente vai estar conversando com essa implementação que por sua vez vai fazer tudo que necessário para falar a língua o formato e e a forma de envio para o sistema externo aqui então a gente já falou de separação de responsabilidades que é o que a gente tá fazendo aqui isso aqui é o centro do meu sistema estou separando e o código da implementação da da Integração tá separado separação de responsabilidade projetos se solução separado em projetos em camadas mostrei nas outras figuras Mas a gente pode encarar esse adapter também como um projeto separado e aí

agora a gente falou de injeção de dependência que é fazer essa relação aqui eh da interface com a implementação usando esse exemplo de ports and adapters beleza para dar uma ideia aqui avançar um pouquinho nesse mesmo desenho vamos lá tem o mesmo desenho só que uma figura diferente aqui né a gente tem aqui o nosso domain tem os US Case tem toda a aplicação interna tem as portas certo que seriam as interfaces aqui aqui percebe que tem uma segunda subdivisão aqui que são os adapters então isso aqui é um adapter que se conecta nessa interface

né que implementa essa interface que que conversa com ela de alguma forma não é só injeção de dependência necessariamente eu posso ter outras coisas aqui no meio olha olha esse exemplo aqui esse aqui eu tenho uma implementação só aqui desse outro canto aqui eu tenho três implementações certo aqui eu tenho duas E aí essa esses adaptadores eles são os caras que fazem o trabalho sujo mesmo né né eles convertem as coisas eles sabem eh o o código que que diz respeito a nós que sabe conversar ou receber ali eh coisas do sistema externo vão est

nesses adapters E aí esses azuizinhos aqui são os sistemas externos mesmo os componentes externos os irps que eu preciso me integrar sistemas de mercado enfim né Vamos lá avançando para a figura mais vamos dizer assim clássica e e mais ã complexa né da arquitetura hexagonal aqui que até eu posso fazer um vídeo e tal depois sobre só sobre isso a ideia aqui não é falar sobre arquitetura hexagonal mas trazer essa ideia de divisão né que é muito muito legal e por que que eu trouxe essa imagem porque aqui fica muito muito explícito essa divisão né

é um doss conceitos que é trazido aqui e enfim aqui o que que eu quero trazer Olha só as portas como elas são exemplificadas aqui tá então por exemplo olha só aqui a porta de notificações tá vendo aqui ó notifications e tá vendo que tem um izinho esse izinho aqui é remetendo a ideia de interface tá que é o que eu tava falando perceba que a interface de notificações que é o meu sistema interno ele vai fazer alguma coisa ele vai calcular o imposto por exemplo né usend o mesmo exemplo E aí ele vai disparar

um uma notificação falando ó imposto calculado imposto do tipo x calculado valor tal vamos supor não necessariamente precisava falar o valor mas aqui vou colocar como exemplo beleza e aí ele dispara isso para uma interface aqui né sabendo falar somente só chegando a nível de abstração e aqui eu tenho dois adapters esses dois adapters o que que são é um adapter para e-mail e outro para SMS então perceba que são adaptadores para conseguir converter a informação de uma notificação do formato de domínio que veio do centro né foi do da publicação de um evento que

aconteceu no meu domínio no meu na minha aplicação e eu preciso propagar isso através de um SMS e de um e-mail então o adapter de smms vai pegar essa informação converter pro formato de sms saber como para se se conversar com sms server que aqui pode ser o sistema externo então um provider de sms aí do mercado que sei lá uma ap que sabe enviar SMS para aparelhos e esse adapter vai saber falar a língua desse SMS server e vai se comunicar com ele mesma coisa o e-mail converto informação eh pegar formato do e-mail lá

com assunto corpo do e-mail remetente enfim e vou me comunicar com um servidor de e-mail então pode ser um serviço externo pode ser um servidor de e-mail smtp configurado internamente Enfim então tenho dois sistemas externos que eu vou ter que propagar essa notificação isso aqui não se engane são integrações né Por mais que não seja um sistema irp o sistema de mercado enfim e é ele é um sistema externo eu não quero colocar a lógica de saber configurar um SMS um e-mail aqui dentro do meu domain eu deixo isso com um adapter separado Inclusive eu

não tenho que ter só uma implementação de sistema externo nesse caso é um bom exemplo porque eu tô tendo que me integrar com dois sistemas ao mesmo tempo então uma notificação vai gerar duas integrações uma por sms outra por e-mail e aqui tem outros exemplos né aqui eh um uma notificação que pode ser gerada e eu posso implementar por exemplo um adaptador que é um event bus que por por consequência aqui por de ser um adapter que vai ter que publicar esse evento em algum lugar ele vai se se se conectar num message bus que

também pode ter outro adapter Olha só como vai ficando como eu vou conseguindo segregar as responsabilidades né message bu vai também ter um adapter aqui queer saber falar com algum mecanismo de message broker message k E aí o meu message bus pode se plugar num Rabbit mi num Kafka num aure service bus enfim né E aqui ele até coloca um pouquinho a mais né e adapter aqui é o message e vamos dizer uma implementação de um intermediário aqui mais um adapter para saber falar os a língua dos message Brokers diferentes então tem vários exemplos D

para se telar aí com exemplos nessa imagem né Ah eu tenho uma interface aqui que responsável por busca aí eu tenho um adaptador que vai eh conseguir traduzir conversar com algum tipo de mecanismo de busca pode ser um elastic Search por exemplo aquele exemplo de ORM que eu tava dando de de acesso a dados de banco né e de banco de dados né Eh aqui eu tenho um uma porta que é uma interface de persistência então Eh aqui saindo um pouco da ideia de sistemas externos né mas não deixa de ser também né Eh aqui

eu tenho uma implementação do adaptador ã de ORM específico então pode ser um RM aqui o entity Framework né ou um n hybernate por exemplo E aí nesse urm aqui ele tá implementado aqui de tal forma que ele consegue ter vários adaptadores que podem conversar nesse caso com esite ou mycle po e sk server Enfim então Perceba como essa separação de responsabilidades torna a a nossa mais fácil para dar manutenção em trechos ah deu problema só no sms que não tá Enviando SMS eu venho aqui e altero o código dou manutenção aqui projeto separado uma

camada separada e aqui internamente eu não sofro com esses detalhes de implementação externos beleza vamos lá e tem um ponto também a gente já falou aqui de separação de responsabilidades a gente já falou de projeto separado é ou camada separada injeção de dependência mas integrações nem sempre e são tão simples nem sempre são código escrito só numa camada e tudo funciona muitas vezes eu preciso configurar Então aquela integração né E aí tem integrações de diferentes e tipos de complexidade níveis de complexidade Então você ter uma configuração uma tela de configuração um meio de configurar a

sua e integração você traz o que pro sistema flexibilidade vou dar um exemplo aqui não se não se eh prendam muito aos exemplos que tá aqui Eu só coloquei uma tela de um print de um sistema qualquer aí só para mostrar como que pode ser feita a integração ou uma tela eventualmente uma tela de configuração mas pegando o exemplo do e-mail do e-mail ou do SMS aqui né o e-mail aqui Talvez eu tenha que configurar vou implantar esse sistema no cliente a ah o cliente a sempre quer mandar o e-mail com o remetente sistema @

domínio dele né Você não vai colocar essa informação fixa no código hardcode né então você precisa que essa informação venha de algum lugar de uma configuração onde pode ser essa configuração configuração em arquivo configuração e numa estrutura de configuração montada no teu banco de dados né em tabelas lá um sistema de gestão de configurações seja criado por você um sistema de mercado que existe só para isso também né sistema de gestão de de configurações por exemplo então isso é algo que traz também um diferencial de para não sujar é suas aplicações com detalhes com informações

que precisam ser flexíveis dependendo de do do ambiente onde você e faz o Deploy você implanta a a sua aplicação você vai ter valores de detalhes das integrações que vão ser diferentes para cada IMP ação vou dar um exemplo nesse próprio print aqui e se for nesse caso né ó ele tá aqui tá configurando o nível de log que ele quer dar para essa implantação para a my application por exemplo aqui né Se for em um ambiente se for aqui em um ambiente de q ou Dev então o environment for Dev eu posso configurar essa

chave aqui que vai refletir lá no log do sistema externo de log que eu tô usando por exemplo eu posso colocar nível debug Ou seja eu quero é desenvolvimento quero pegar todos os logs porque eu tô desenvolvendo quero ver fazer o O debug Ali ver se tá funcionando se não tá mas quando eu trocar para um ambiente de prod é interessante que eu não deixe o nível de log tão agressiv quanto o debug Ah vou colocar um info vou colocar um warning vou colocar enfim né aí depende a da sua necessidade mas tendo uma gestão

de configuração um local Centralizado muitas vezes para eu configurar as minhas integrações eh por ambiente por versão aqui daí aqui a imaginação é o limite né É por data por contexto enfim por n coisas é me traz flexibilidade de implantação então no ambiente x eu quero configurar assim no ambiente Y quero configurar assado quando quando você tem um Saas por exemplo né um sistema aí que você vende como serviço onde você tem uma plataforma só mas se você o produto é instalado em cada cliente aí você tem implanta ações para cada cliente que precisam ser

configuradas conforme o cenário daquele cliente então quando você chega em planta teu sistema você vai configurar suas integrações E aí um uma coisa que dá muito certo é você ter a sua própria gestão de configurações de integrações falando Ah o sistema a aqui de e mail eu vou parar o remetente que seria a chave configurar o valor tal E aí aqui é um um exemplo que funciona muito bem tá configurações em formato de chave e valor então tenho chave que seria a a relação que você vai ter para pegar essa configuração lá no código para

não ter que colocar ele hardcoded então você vai pegar a chave de configuração vai usar lá o valor vai ser o valor que você vai trazer através da chave e aqui algumas informações a mais por exemplo você quer criptografar essa informação aqui para ela não ficar eh em PL text no banco de dados por exemplo aí a gente tem várias opções aí de como implementar Essa gestão de configurações mas o ponto aqui por que ter uma gestão de configurações uma tabela arquivo E aí você vai modernizando quanto você quiser né porque te dá flexibilidade de

implantação de a agilidade em troca de configuração né você não precisa derrubar aplicação para voltar e tal aí dependendo como você implementa obviamente né mas te D flexibilidade isso é muito importante quando a gente fala de integração tá flexibilidade dos doss grandes valores que você pode dar pro teu sistema que é implantado de formas diferentes beleza aí o último ponto aqui que até tem um um um exemplo aqui na tela né versionamento né é interessante que você mantenha as versões das integrações eh segmentadas ou consiga separar elas de alguma forma para você lidar com diferentes

versões mesmo do sistema externo tá por quê porque pode ser que o teu sistema o sistema externo num C esteja na versão 1.2 no sistema externo do cliente B esteja na 1.5 e entre essas versões de sistema externo teve Break Change ou seja T alteração que quebra aplicação então pode ser que vou voltar aqui um pouquinho vocês entenderem pode que você tenha que ter um adap aqui MS versão 1.2 e outro pra versão 1.5 pode colocar no mesmo adapter pode colocar desde que você faça a gestão dessa desse versionamento e de forma configurável que você

consigue escolher Então quando você vai implantar no cliente por exemplo ou no seu ambiente lá você consegue escolher vou usar o adaptador de sms da empresa tal versão 1.2 E aí ele sabe falar os campos da api lá da versão 1.2 desde que o seu serviço externo né da aplicação externa também versione né ele tem lá uma pzinha lá para versão 1.2 um pra versão 1.5 que algum momento vai morrer a versão 1.2 vai ficar só 1.5 que é o momento Onde você consegue também descontinuar o seu adaptador de versão 1.2 Então esse versionamento é

importante por é ele existe justamente porque ah existe um período de transição né quando a gente tem quebra de compatibilidade a gente versiona para que dê tempo de um um sistema ou clientes micr para versão mais nova se adequem sem que durante esse processo a gente tenha quebra ou parada no serviço Beleza então o versionamento das integrações é tão importante quanto o versionamento de uma API sua ali que eh você entrega externamente né porque você entregando uma API versionada não esqueça que você pode ser o sistema externo de outra eh de outro sistema né De

outra empresa que vai querer se integrar com você então se preocupar com versionamento Não é só para as nossas apis e tudo mais eh é nessa questão de a gente se integrar com sistemas externos também versionar a implementação da própria integração muito bem agora para finalizar aqui trazer um último tópico eh o conjunto de tópicos aqui para falar um pouquinho de outras preocupações que a gente tem que ter eh quando a gente tá fazendo integrações e algumas dicas também tá o intuito do vídeo aqui não é falar sobre Integração em si a gente pode pode

falar Eh muito mais sobre isso mas aqui fica como um bônus vamos dizer assim não necessariamente em relação a ah ao tema desse vídeo que é deixar de sujar Nossa aplicação com integrações né Eh mas aqui dicas bônus sobre integração tá primeira coisa é quando você vai fazer integração comos sistemas externos eh ou sistemas externos vão fazer integração com você sempre opte sempre que possível por uma abordagem assíncrona não é legal eh E tem alguns casos que precisa ser síncrona Eu sei né Por exemplo consulta de dados na sua maioria Quando alguém vem consultar dados

numa pessoa por exemplo você precisa integrar o dado eh entregar o dado sincron M mas quando vai fazer uma operação ou até mesmo uma consulta você pode de prometer né entregar uma Promise ali que você vai entregar aquele dado no endp do cliente depois né Então essa e visão assíncrona de integração é muito benéfica por quê Porque você não fica pendurado né você não pendura os dois sistemas durante o processamento E aí eles vão fazer outras coisas você vai fazer outras coisas e quando o processamento tiver completo você eh entrega o resultado então basicamente se

alguém vem num pedir um dado para você ou pedir um processamento para você então calcule ã x né você vai falar OK recebi seu pedido com a solicitação de eh somar aqui ou calcular alguma coisa vou te entregar em um endp que você vai me dizer daqui a pouco quando tiver pronto isso aí está prometendo você tá falando que você recebeu a solicitação aí assincronamente você né você vai guardar essa solicitação assincronamente você vai processar ela e assim que possível e o mais rápido possível você vai entregar essa informação eh num endp dele de resultado

beleza segundo ponto aqui de como dica de para integrações boas práticas né preocupações vamos dizer assim eh você tem que ter resiliência e retent ativas quando necessário então pode ser que um algo que te peçam algum processamento de alguma integração que chegue você tem que guardar ela até porque você vai eh optar né sempre que possível por uma abordagem assíncrona Então você tem que guardar se acontecer algum erro no processamento e a tua integração demandar que você represse você tem que ter isso guardado para que você continue tentando seja numa estratégia de fila seja no

próprio por banco de dados Enfim então tem integrações E aí é peculiar de cada integração você ter que retentar coisas então você tem que ter essa estratégia bem na cabeça mas um ponto importante é as retent ativas não podem ser para sempre Então tem que ter um limite Por mais que você tenha que ter uma estratégia de tentar tentar tentar você não vai tentar isso a de eterno coloque alguma e trava algum ponto de parada que avise eh de forma final para o sistema de destino que ok ó tentei n vezes não consigo mais se

você precisar disso me pede de novo senão corre o risco do teu sistema ficar em looping ali para sempre terceiro ponto a parte de log rastreamento e monitoramento né integrações como a gente tá falando falando de dois sistemas distintos que se comunicam eh muitas vezes pela rede ou por algum outro formato sei lá arquivo enfim eh são sistemas que não estão sob eh o sistema externo pelo menos né não está sobre o seu Cuidado então você documentar aí logar né monitorar passo a passo o que integração fez é muito importante para dar visibilidade e transparência

para o processo que tá acontecendo senão o usuário nunca vai saber o que aconteceu quando acontec quando aconteceu por aconteceu o erro qual que foi para ele fazer ali uma busca conseguir consertar para rodar de novo a integração Então você tem que expor dados suficientes para dizer o que aconteceu com essa integração então uma tela de monitoramento logs enfim próximo ponto é atenção na segurança e autorização não é porque você tem que integrar os sistemas que o você conseguindo fazer ele se comunicar ali mandar informação de um pro outro trabalho tá feito não você tem

que se preocupar em manter a segurança interna Afinal é é um agente externo estranho que está tentando fazer algo no teu sistema E aí você abrindo uma porta externa né ou até enviando também eh você está suscetível a vulnerabilidades a ataques enfim né então você tem que manter sempre a autenticação tem que se preocupar e autorização ou seja permissões se alguém pediu para você fazer alguma coisa e é um usuário externo que não tem permissão para fazer algo interno barra ele né Eh você tem que tomar cuidado não é só sua ui lá sua interface

que precisa ter cuidado com a autorização de usuários integrações de sistemas externos também e por fim algo que foi já assunto eh de de um vídeo aí anterior né documentação você precisa ter documentação eh o mais detalhada possível de integrações visto que integrações falam form atos diferentes se comunicam de formas diferentes tem autorizações de formas diferentes e versões diferentes então é muito difícil e nem sempre as as documentações do sistema externo são boas né Às vezes precisa documentar o processo de integração que você fez como que precisa configurar a integração isso é muito importante no

momento da implantação eh ter uma documentação da das integrações do seus adapters ali é muito importante para que você tenha D visibilidade aí não na operação no na execução da Integração mas sim na configuração na implantação de como foi feito até uma documentação arquitetural como foi dito na no vídeo sobre adrs que se você não viu o vídeo no canal busca aí é como documentar suas decisões arquiteturais enfim documentação é importante não pode ser negligenciada também muito bem pessoal Então esse é o vídeo de hoje espero que vocês tenham gostado não esqueça de deixar um

gostei aí um like se inscrever no canal deixar os seus feedbacks entrar lá na nossa comunidade do discord e se você tem um amigo que tá integrando sistemas tá enfrentando esses problemas aqui quer saber de boas práticas compartilhe esse vídeo com ele que acredito que vai ser de grande ajuda também mais uma vez espero que vocês tenham gostado e a gente se vê no próximo vídeo valeu