{"id":1936,"date":"2021-06-04T13:18:13","date_gmt":"2021-06-04T16:18:13","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=1936"},"modified":"2024-01-12T11:36:35","modified_gmt":"2024-01-12T14:36:35","slug":"fundamentos-para-arquiteturas-baseadas-em-eventos-eda","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/","title":{"rendered":"Cap 3.4 Fundamentos para arquiteturas baseadas em eventos (EDA)"},"content":{"rendered":"

Sistemas de software apoiam ou automatizam a execu\u00e7\u00e3o de atividades. A ocorr\u00eancia de uma atividade pode ser descrita como “evento”.<\/strong> Sempre que um evento acontece,\u00a0 \u00e9 poss\u00edvel gerar um “registro” que o descreva. Este “registro descritivo”, por sua vez, pode conter informa\u00e7\u00f5es como o tipo da atividade,\u00a0 quando ela aconteceu, al\u00e9m de outros dados relevantes associados.<\/p>\n

A venda de um produto, em um site de e-commerce<\/em>, por exemplo, \u00e9 um evento. O registro associado seguramente conteria o momento da venda, o produto que foi vendido, as condi\u00e7\u00f5es de pagamento e entrega, o cliente que realizou a compra, entre outras informa\u00e7\u00f5es.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" A ocorr\u00eancia de um evento frequentemente estar\u00e1 associada a uma mudan\u00e7a relevante do “estado interno” de um componente.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A captura de dados de um sensor metereol\u00f3gico, em sistemas com IoT para suporte a ind\u00fastria agro, tamb\u00e9m \u00e9 um evento. O registro associado poderia conter a identifica\u00e7\u00e3o do sensor, o momento da coleta, temperatura e outras informa\u00e7\u00f5es relacionadas a condi\u00e7\u00e3o clim\u00e1tica.<\/p>\n

Se um “registro descritivo” for gerado para cada atividade relevante suportada por um componente, ent\u00e3o, pode-se assumir que a opera\u00e7\u00e3o desse componente ir\u00e1 produzir um “fluxo de eventos” (event stream<\/em>).\u00a0<\/strong>Se este fluxo for apropriadamente armazenado, constituir\u00e1 uma “fonte da verdade atemporal”. Afinal, conter\u00e1 um registro n\u00e3o apenas das mudan\u00e7as de estado que aconteceram, mas tamb\u00e9m as “motiva\u00e7\u00f5es” (comportamentos) que geraram tais mudan\u00e7as, habilitando event sourcing<\/em>.<\/p>\n

\r\n

Defini\u00e7\u00e3o: Event Sourcing<\/p>\r\n

<\/p>\n

Event sourcing<\/em> consiste no armazenamento de todos os registros descritivos de eventos significativos para o estado de um componente, ao longo do tempo, de forma a permitir, por meio da “replay<\/em>“, a restaura\u00e7\u00e3o “posi\u00e7\u00f5es de estado” consolidadas em qualquer momento do tempo.<\/p>\n

<\/p>\r\n<\/div>\n

Se um componente “produzir” os registros descritivos de um evento, publicando-o em algum mecanismo que permita “observa\u00e7\u00e3o”, ent\u00e3o ser\u00e1 poss\u00edvel que outros componentes possam “consumir” tais registros,\u00a0 apropriadamente, disparando atividades complementares ou atualiza\u00e7\u00f5es internas de estado.<\/strong> Eventualmente, esses “componentes consumidores”, ao regir um evento, tamb\u00e9m atuem como “produtores”.<\/p>\n

\r\n

EDA e Domain-driven design<\/p>\r\n<\/p>\n

A elabora\u00e7\u00e3o de arquiteturas\u00a0event-driven\u00a0<\/em>tem sido facilitada pelo uso de\u00a0Domain-driven Design<\/em>.<\/p>\n

A identifica\u00e7\u00e3o de contextos delimitados, com suas respectivas responsabilidades, faz emergir naturalmente os “eventos de dom\u00ednio”, utilizados sobretudo para a comunica\u00e7\u00e3o entre contextos diversos, de maneira alinhada as demandas do neg\u00f3cio.<\/p>\n

Ali\u00e1s, uma das t\u00e9cnicas mais populares para “descoberta” do dom\u00ednio \u00e9 centrada em eventos: event storming.<\/em><\/p>\n

<\/div>\n

Voltando ao cen\u00e1rio de um sistema de e-commerce,\u00a0<\/em>a publica\u00e7\u00e3o, por parte do componente “carrinho”, da consolida\u00e7\u00e3o de uma venda, pode servir como “gatilho” para que o componente “cobran\u00e7a” efetue<\/p>\n

Event-driven architectures <\/em>implementam as caracter\u00edsticas descritas nos par\u00e1grafos anteriores.<\/strong> Elas se destacam, acima de tudo pela redu\u00e7\u00e3o dram\u00e1tica do acoplamento e melhora da responsibividade.<\/p>\n

 <\/p>\n

\r\n

Diferen\u00e7a entre responsividade e desempenho<\/p>\r\n<\/p>\n

Frequentemente, h\u00e1 confus\u00e3o entre responsividade e desempenho.<\/p>\n

A responsividade<\/strong>\u00a0\u00e9 um atributo de qualidade que tem rela\u00e7\u00e3o com o tempo que um usu\u00e1rio ou sistema cliente tem de esperar para, ap\u00f3s iniciar alguma opera\u00e7\u00e3o, poder iniciar outra.<\/p>\n

O desempenho<\/strong>, tamb\u00e9m um atributo de qualidade, tem rela\u00e7\u00e3o com o tempo total demandado por um sistema computacional para processar uma opera\u00e7\u00e3o completamente.<\/p>\n

Assim, um sistema pode ser responsivo sem ser perform\u00e1tico.<\/p>\n

<\/div>\n

Desmistificando Event-driven Architectures<\/em><\/h2>\n

Arquiteturas event-driven\u00a0<\/em>atendem objetivos de neg\u00f3cio, respeitando restri\u00e7\u00f5es, atingindo determinados padr\u00f5es em atributos de qualidade, adotando padr\u00f5es e pr\u00e1ticas de design <\/em>que colocam “eventos” no centro.<\/p>\n

\r\n

Defini\u00e7\u00e3o: Evento<\/p>\r\n

<\/p>\n

\u00c9 o reconhecimento formal de um fato que, provavelmente, provocou uma modifica\u00e7\u00e3o relevante no estado de uma aplica\u00e7\u00e3o.<\/p>\n

No dia-a-dia, o termo “evento” tamb\u00e9m \u00e9 frequentemente associado com “registros descritivos” contendo informa\u00e7\u00f5es sobre um evento propriamente dito.<\/p>\n

<\/p>\r\n<\/div>\n

Entretanto, \u00e9 importante que se destaque que dois sistemas, alegadamente event-driven<\/em>, podem adotar padr\u00f5es e pr\u00e1ticas de design <\/em>completamente distintas.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Dois sistemas podem ter arquiteturas event-driven,\u00a0<\/em>entretanto, com caracter\u00edsticas significativamente disitintas.<\/p>\n

<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

The Many Meanings of Event-Driven Architecture<\/p>\r\n<\/p>\n

Martin Fowler<\/a>, em uma palestra para o GOTO, em 2017, fala sobre os “muitos entendimentos” a respeito<\/p>\n

\r\n

Acessar v\u00eddeo<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Ativa\u00e7\u00f5es por notifica\u00e7\u00f5es<\/h4>\n

H\u00e1 tr\u00eas “modelos mentais” para ativa\u00e7\u00e3o entre servi\u00e7os:<\/p>\n

    \n
  1. ativa\u00e7\u00e3o ativa s\u00edncrona, via chamada de APIs, quando um servi\u00e7o precisa recuperar informa\u00e7\u00f5es sob controle de outro ou, tamb\u00e9m, quando um servi\u00e7o deseja “disparar” uma a\u00e7\u00e3o em outro servi\u00e7o.<\/li>\n
  2. ativa\u00e7\u00e3o ativa ass\u00edncrona, via envio de mensagens (comandos\u00a0 ou queries<\/em>), atrav\u00e9s de um message-broker<\/em><\/li>\n
  3. ativa\u00e7\u00e3o passiva ass\u00edncrona, via eventos, atrav\u00e9s de\u00a0event-broker<\/em><\/li>\n<\/ol>\n
    \n

    Arquiteturas event-driven<\/em> baseiam-se, frequentemente, no terceiro modelo.<\/strong><\/p>\n

    \"\"<\/p>\n

    \r\n

    Defini\u00e7\u00e3o: Event-broker<\/p>\r\n

    <\/p>\n

    Event-broker<\/em> \u00e9 um componente respons\u00e1vel por “receber eventos”, armazen\u00e1-los em uma fila ou em\u00a0streams<\/em>, e disponibiliz\u00e1-los para outros componentes.<\/p>\n

    Eventualmente,\u00a0event-brokers<\/em>, realizam tarefas administrativas como compacta\u00e7\u00e3o.<\/p>\n

    <\/p>\r\n<\/div>\n

    Ativa\u00e7\u00e3o passiva ass\u00edncrona habilita responsibividade e resili\u00eancia.<\/strong><\/p>\n

    Event sourcing<\/em><\/h4>\n

    Fazer com que um sistema lance eventos de notifica\u00e7\u00e3o para toda modifica\u00e7\u00e3o no estado de uma entidade abre espa\u00e7o para algumas solu\u00e7\u00f5es interessantes.\u00a0Podemos, por exemplo, usar os eventos de notifica\u00e7\u00e3o para, al\u00e9m de permitir implementa\u00e7\u00e3o desacoplada de consist\u00eancia eventual entre aplica\u00e7\u00f5es,\u00a0 contar a \u201chist\u00f3ria\u201d de entidades, atrav\u00e9s de uma t\u00e9cnica conhecida como Event Sourcing<\/em>.<\/p>\n

    A ideia central da t\u00e9cnica \u00e9 reconhecer que o estado de uma entidade \u00e9 \u201cexplicado\u201d pela ocorr\u00eancia de uma sequ\u00eancia clara de eventos, em uma ordem determinada.<\/p>\n

    Com posse do hist\u00f3rico de eventos de notifica\u00e7\u00e3o de altera\u00e7\u00e3o de estado, podemos restituir qualquer um dos \u201cestados hist\u00f3ricos\u201d de uma entidade, bastando, para isso, que realizar um replay <\/em>do seu hist\u00f3rico de eventos at\u00e9 o ponto apropriado.<\/p>\n

    \"\"<\/p>\n

    Em termos simples, mantendo o hist\u00f3rico de eventos armazenado, podemos \u201crecuperar\u201d o estado de uma entidade, em qualquer momento. Podemos tamb\u00e9m saber quando mudan\u00e7as ocorreram, quem fez essas mudan\u00e7as e qual foi a inten\u00e7\u00e3o de neg\u00f3cio. Poderoso, por\u00e9m complexo!<\/p>\n

    Sistemas que usam\u00a0event sourcing\u00a0<\/em>costumam manter, al\u00e9m da base de eventos, uma outra base com materializa\u00e7\u00f5es do estado da entidade em algum momento (geralmente o atual).<\/p>\n

    \"\"<\/p>\n

    Essa materializa\u00e7\u00e3o \u00e9 \u00fatil por ser extermamente f\u00e1cil de pesquisar. Podemos pensar essas materializa\u00e7\u00f5es como \u201cfotografias\u201d do estado da entidade em algum momento. Talvez por isso, convencionou-se utililizar a designa\u00e7\u00e3o snapshot.\u00a0<\/em><\/p>\n

    A base de dados utilizada para armazenar eventos geralmente \u00e9\u00a0nosql<\/em>. A base para os snapshots\u00a0<\/em>pode ser quaquer uma, inclusive relacionais. Ali\u00e1s, Greg Young, que formalizou o conceito de\u00a0Event Sourcing<\/em>, criou um banco de dados para armazenar eventos chamado\u00a0EventStore<\/a><\/em>.<\/p>\n

    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\"\r\n

    Datomic: desafios e benef\u00edcios de um banco de dados imut\u00e1vel <\/p>\r\n<\/p>\n

    O Nubank utiliza Datomic, uma base de dados imut\u00e1vel, incremental, registrando eventos.<\/p>\n

    \r\n

    Acessar v\u00eddeo<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nH\u00e1 diversas implementa\u00e7\u00f5es de event sourcing <\/em>em sistemas de mercado. Ou seja, existem diversos sistemas que mant\u00e9m um hist\u00f3rico de eventos para justificar o estado de suas entidade.\u00a0De qualquer forma,\u00a0event sourcing\u00a0<\/em>est\u00e1 longe de ser t\u00f3pico ou pr\u00e1tica comum. H\u00e1 uma diversidade gigantesca de complica\u00e7\u00f5es para uma implementa\u00e7\u00e3o correta e precisa existir uma justificativa muito forte para ado\u00e7\u00e3o.\n

    Event-carrier state transfer<\/em><\/h4>\n

    Event brokers\u00a0<\/em>se convertem em fonte da verdade, substituindo demandas naturais por recupera\u00e7\u00e3o de estado atrav\u00e9s de requisi\u00e7\u00f5es de APIs, por consolida\u00e7\u00e3o de dados em bases locais, mediante processos de sele\u00e7\u00e3o, transforma\u00e7\u00e3o e redu\u00e7\u00e3o.<\/p>\n

    \"\"<\/p>\n

    Duas topologias para colabora\u00e7\u00e3o em EDA<\/h2>\n

    H\u00e1 duas topologias fundamentais para implementa\u00e7\u00e3o de colabora\u00e7\u00e3o <\/strong>de arquiteturas event-driven<\/em>. A primeira delas \u00e9 baseada na ideia de mediadores ativos e orquestra\u00e7\u00e3o. A segunda, \u00e9 baseada na utiliza\u00e7\u00e3o de intermediadores (brokers<\/em>) e coreografia.<\/strong><\/p>\nImplementa\u00e7\u00f5es event-driven<\/em> que utilizam mediadores ativos e orquestra\u00e7\u00e3o s\u00e3o mais apropriadas para cen\u00e1rios onde o tratamento de eventos precise ser gerenciado, com forte controle sobre falhas e sobre o andamento. Por outro lado, implementa\u00e7\u00f5es com brokers<\/em> e coreografia s\u00e3o mais apropriadas para estruturas din\u00e2micas, fire-and-forget<\/em>.\n

    \n

    Ambas as abordagens assumem que um “evento inicial” ser\u00e1 capturado pelo sistema iniciando processamento.<\/p>\n

    Usando brokers e coreografia<\/h4>\n

    Diferente da abordagem utilizando mediadores e orquestra\u00e7\u00e3o, a utiliza\u00e7\u00e3o de brokers<\/em> e coreografia se destaca pela inexist\u00eancia de um componente central, respons\u00e1vel pelo sequenciamento dos trabalhos.<\/strong><\/p>\n

    Nessa topologia, impl\u00edcita, componentes executores s\u00e3o acionados de maneira encadeada, onde um componente executor encaminha um evento para um message broker (como RabbitMQ<\/a> ou outras implementa\u00e7\u00f5es AMQP<\/a>), sempre que conclui seu trabalho, acionando outro(s) componente(s) executor(es), e assim sucessivamente, at\u00e9 que todo o processamento necess\u00e1rio aconte\u00e7a.<\/p>\n

    \"\"<\/p>\nA estrat\u00e9gia de cada componente executor ao encaminhar eventos \u00e9 do tipo fire-and-forget<\/em> e \u00e9 muito importante que todo processamento executado seja notificado, com eventos, ao sistema, ampliando chances de extensibilidade ao custo de desperd\u00edcio de recursos computacionais (com eventos que n\u00e3o s\u00e3o “escutados” por ningu\u00e9m).\n

    \n
    \r\n

    Fire-and-forget<\/p>\r\n<\/p>\n

    Fire-and-forget\u00a0<\/em>\u00e9 um padr\u00e3o de mensageria onde o produtor envia uma mensagem para um consumidor sem esperar resposta.\u00a0Trata-se da\u00a0forma\u00a0mais simples de troca de mensagens. <\/strong><\/p>\n

    Fire-and-Forget<\/em>\u00a0destaca-se pelo baix\u00edssimo acoplamento, afinal o produtor n\u00e3o precisa saber nada sobre seus consumidores, incluindo quantos existem ou o que eles fazem com a mensagem.\u00a0Esse tipo de intera\u00e7\u00e3o sem estado resulta em sistemas de mensagens altamente escal\u00e1veis.<\/p>\n

    A simplicidade e o baixo acoplamento, entretanto, tem seu pre\u00e7o: o tratamento de erros n\u00e3o \u00e9 poss\u00edvel porque n\u00e3o h\u00e1 feedback<\/em> sobre a “entrega” das mensagens. Assim, implementa\u00e7\u00f5es Fire-and-Forget<\/em> devem utilizar mecanismos mais robustos de “entrega” ou aceitarem que algumas mensagens possam ser perdidas. Al\u00e9m disso, \u00e9 importante ter consci\u00eancia de que um consumidor ter\u00e1 pouco a fazer caso a mensagem recebida esteja mal-formada ou com dados inv\u00e1lidos.<\/div>\n

    Tr\u00eas padr\u00f5es de processamento<\/h2>\n

    Componentes executores assumem, basicamente, tr\u00eas padr\u00f5es de comportamento:<\/p>\n

      \n
    1. processamento simples;<\/li>\n
    2. processamento de streams;\u00a0<\/em><\/li>\n
    3. processamento de eventos complexos (complex event processing<\/em> – CEP).<\/li>\n<\/ol>\n
      \n

      Enquanto o padr\u00e3o de processamento simples ocorre tanto arquiteturas orquestradas e coreografadas, processamento de streams <\/em>e de eventos complexos costumam ser implementadas apenas em topologias coreografadas.<\/p>\n

      O detalhamento desses padr\u00f5es de execu\u00e7\u00e3o est\u00e3o al\u00e9m do escopo desse livro. Ali\u00e1s, h\u00e1 obras inteiras dedicadas ao tema.<\/p>\n

      Processamento simples<\/h4>\n

      Componentes executores que operam adotando processamento simples, “escutam” um determinado tipo de mensagem e executam, para cada ocorr\u00eancia, algum trabalho. Trata-se do padr\u00e3o mais f\u00e1cil de implementar e, provavelmente, mais comum.<\/p>\n

      Processamento de streams<\/em><\/h4>\n

      Componentes executores que operam adotando processamento de streams<\/em>, podem “escutar” diversas ocorr\u00eancias de eventos mas s\u00f3 executam algum processamento quando algum crit\u00e9rio \u00e9 atendido. Estes executores operam agregando, analisando e processando\u00a0streams\u00a0<\/em>de eventos.<\/p>\n

      Considere, por exemplo, um componente executor recebendo todas as transa\u00e7\u00f5es de um determinado cart\u00e3o de cr\u00e9dito. Caso duas transa\u00e7\u00f5es presenciais (dois eventos) sejam executadas em localidades afastadas a uma dist\u00e2ncia maior do que aquela que poderia ser percorrida no intervalo de tempo entre as ocorr\u00eancias, este\u00a0executor\u00a0<\/em>poderia gerar um evento (agrega\u00e7\u00e3o) indicando possibilidade de fraude.<\/p>\n

      Processamento de eventos complexos (CEP)<\/h4>\n

      Componentes executores que operam adotando processamento de eventos complexos, identificam eventos significativos (como oportunidades ou amea\u00e7as) a partir de eventos menos expressivos, oriundos de dois ou mais streams<\/em>.<\/p>\n

      Contratos para eventos<\/h2>\n

      O acoplamento entre servi\u00e7os, tradicional em solu\u00e7\u00f5es que n\u00e3o t\u00eam EDA, \u00e9 substitu\u00eddo por acoplamento com contratos dos registros descritivos dos eventos.<\/p>\n

      Uma bom contrato indica muito mais do que “algo aconteceu”. Bons contratos indicam “tudo que aconteceu”, servindo, de fato, como “fonte da verdade” quando uma verifica\u00e7\u00e3o ocorrer (sem necessidade de pesquisas complementares).<\/p>\n

      Idealmente, os “esquemas” associados a contratos devem ficar registrado em um\u00a0registry.<\/em><\/p>\n

      \"\"<\/p>\n

      Reatividade natural<\/h2>\n

      Arquiteturas\u00a0event-driven, <\/em>quando bem implementadas,\u00a0s\u00e3o naturalmente reativas. Ou seja, s\u00e3o responsivas, resilientes, el\u00e1sticas e orientadas a mensagens.<\/p>\n

      A responsividade<\/strong> \u00e9 natural ao processamento ass\u00edncrono, comum em EDAs.<\/p>\n

      A resili\u00eancia<\/strong>, por sua vez, \u00e9 garantida pela estabilidade dos mecanismos de mensageria,\u00a0<\/em>que \u201cseguram\u201d os eventos caso exista alguma instabilidade nos componentes processadores.<\/p>\n

      A elasticidade\u00a0<\/strong>\u00e9 poss\u00edvel gra\u00e7as ao desacoplamento dos componentes executores dos demais.\u00a0<\/em>Em princ\u00edpio, quando a demanda sobe pela ocorr\u00eancia de mais eventos,\u00a0componentes executores\u00a0<\/em>mais pesados podem ter novas inst\u00e2ncias criadas e descartadas conforme a escala oscila.<\/p>\n

      Por fim, o \u201cfluxo dos eventos\u201d \u00e9, quando \u00e9 usado um mecanismo adequado de mensageria, naturalmente orientado a mensagens<\/strong>.<\/p>\n

      Conway, outra vez!<\/h2>\n

      Arquiteturas event-driven\u00a0<\/em>geralmente s\u00e3o particionadas pelo dom\u00ednio, o que facilita a forma\u00e7\u00e3o de\u00a0times especialistas para caracter\u00edsticas do neg\u00f3cio.<\/p>\nGeralmente, a estrutura dos times ir\u00e1 replicar a topologia dos componentes executores e mediadores. Pelo alto acoplamento aferente, a infraestrutra dever\u00e1 ter ownership\u00a0<\/em>de um time dedicado, mesmo com pr\u00e1ticas maduras de DevOps, afim de evitar difus\u00e3o de responsabilidades. O mesmo \u00e9 v\u00e1lido para componentes mediadores em fun\u00e7\u00e3o do alto acoplamento eferente.\n

      Indica\u00e7\u00f5es e contraindica\u00e7\u00f5es<\/h2>\nArquiteturas event-driven\u00a0<\/em>s\u00e3o poderosas e est\u00e3o alinhadas com boas pr\u00e1ticas para implementa\u00e7\u00e3o de sistemas modulares, at\u00e9 mesmo com microsservi\u00e7os. Entretanto, s\u00e3o naturalmente complexas e quando esta complexidade n\u00e3o for bem justificada, a ado\u00e7\u00e3o deste estilo poder\u00e1 representar incremento de custo dif\u00edcil de justificar.\n
      \nA capacidade de lidar melhor com cen\u00e1rios din\u00e2micos e complexos vem com o custo indireto de lidar com consist\u00eancia eventual. As facilidades para escalar vem com o custo indireto de maior dificuldade para monitorar. As facilidades para adaptar e responder a demandas do neg\u00f3cio vem acompanhadas de maior dificuldade para testes de integra\u00e7\u00e3o.\n
      \n

      \/\/ TODO<\/h2>\n

      Antes de avan\u00e7ar para o pr\u00f3ximo cap\u00edtulo, fa\u00e7a as seguintes reflex\u00f5es:<\/p>\n

        \n
      1. O sistema em que est\u00e1 trabalhando agora lida, naturalmente, com eventos?<\/li>\n
      2. Baseado em sua experi\u00eancia, com que frequ\u00eancia o aumento da complexidade justificaria “transformar” sistemas\u00a0request-driven\u00a0<\/em>em\u00a0event-driven<\/em>?<\/li>\n
      3. Sistemas escal\u00e1veis s\u00e3o, geralmente, ass\u00edncronos. Concorda com essa afirma\u00e7\u00e3o?<\/li>\n
      4. Em que cen\u00e1rios adotaria Event Sourcing<\/em>?<\/li>\n<\/ol>\n

         <\/p>\n","protected":false},"featured_media":3834,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[72],"sessoes":[59],"apendices":[],"capitulos":[32],"class_list":["post-1936","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","url-permanente","sessoes-secao-3","capitulos-capitulo-3-4"],"acf":[],"yoast_head":"\nCap 3.4 Fundamentos para arquiteturas baseadas em eventos (EDA) - Manual do Arquiteto de Software<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Cap 3.4 Fundamentos para arquiteturas baseadas em eventos (EDA) - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Sistemas de software apoiam ou automatizam a execu\u00e7\u00e3o de atividades. A ocorr\u00eancia de uma atividade pode ser descrita como “evento”. Sempre que um evento acontece,\u00a0 \u00e9 poss\u00edvel gerar um “registro” que o descreva. Este “registro descritivo”, por sua vez, pode conter informa\u00e7\u00f5es como o tipo da atividade,\u00a0 quando ela aconteceu, al\u00e9m de outros dados relevantes […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/\" \/>\n<meta property=\"og:site_name\" content=\"Manual do Arquiteto de Software\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/eximiaco\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-12T14:36:35+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/3.4.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"600\" \/>\n\t<meta property=\"og:image:height\" content=\"338\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:site\" content=\"@eximiaco\" \/>\n<meta name=\"twitter:label1\" content=\"Est. tempo de leitura\" \/>\n\t<meta name=\"twitter:data1\" content=\"14 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/\",\"name\":\"Cap 3.4 Fundamentos para arquiteturas baseadas em eventos (EDA) - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/3.4.jpg\",\"datePublished\":\"2021-06-04T16:18:13+00:00\",\"dateModified\":\"2024-01-12T14:36:35+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/3.4.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/3.4.jpg\",\"width\":600,\"height\":338},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Volume 1\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Cap 3.4 Fundamentos para arquiteturas baseadas em eventos (EDA)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"name\":\"Manual do Arquiteto de Software\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\",\"name\":\"EximiaCo\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"width\":150,\"height\":150,\"caption\":\"EximiaCo\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/eximiaco\",\"https:\/\/x.com\/eximiaco\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Cap 3.4 Fundamentos para arquiteturas baseadas em eventos (EDA) - Manual do Arquiteto de Software","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/","og_locale":"pt_BR","og_type":"article","og_title":"Cap 3.4 Fundamentos para arquiteturas baseadas em eventos (EDA) - Manual do Arquiteto de Software","og_description":"Sistemas de software apoiam ou automatizam a execu\u00e7\u00e3o de atividades. A ocorr\u00eancia de uma atividade pode ser descrita como “evento”. Sempre que um evento acontece,\u00a0 \u00e9 poss\u00edvel gerar um “registro” que o descreva. Este “registro descritivo”, por sua vez, pode conter informa\u00e7\u00f5es como o tipo da atividade,\u00a0 quando ela aconteceu, al\u00e9m de outros dados relevantes […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-12T14:36:35+00:00","og_image":[{"width":600,"height":338,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/3.4.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"14 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/","name":"Cap 3.4 Fundamentos para arquiteturas baseadas em eventos (EDA) - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/3.4.jpg","datePublished":"2021-06-04T16:18:13+00:00","dateModified":"2024-01-12T14:36:35+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/3.4.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/3.4.jpg","width":600,"height":338},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-eventos-eda\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/"},{"@type":"ListItem","position":2,"name":"Volume 1","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/"},{"@type":"ListItem","position":3,"name":"Cap 3.4 Fundamentos para arquiteturas baseadas em eventos (EDA)"}]},{"@type":"WebSite","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","name":"Manual do Arquiteto de Software","description":"","publisher":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-BR"},{"@type":"Organization","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization","name":"EximiaCo","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","width":150,"height":150,"caption":"EximiaCo"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/eximiaco","https:\/\/x.com\/eximiaco"]}]}},"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1\/1936","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/types\/volume-1"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/comments?post=1936"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/3834"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=1936"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=1936"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=1936"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=1936"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=1936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

    Usando mediadores ativos e orquestra\u00e7\u00e3o<\/h4>\n

    A principal caracter\u00edstica de uma arquitetura event-driven com mediadores ativos e orquestra\u00e7\u00e3o \u00e9 a presen\u00e7a de um componente orquestrador (o mediador ativo) que gerencia e controla o fluxo de atividades, acionando componentes processadores, de maneira organizada, em tempos apropriados.<\/strong><\/p>\n

    Nessa topologia, expl\u00edcita, um “evento inicial” \u00e9 submetido a uma fila que \u00e9 “escutada” pelo componente mediador. Este componente, por sua vez, “sabe” quais procedimentos que devem ser executados para “tratar” o evento e em que sequ\u00eancia. Por isso, aciona “executores”, notificando-os com eventos atrav\u00e9s de canais de eventos point-to-point<\/em>.\u00a0Toda vez que um componente executor conclui seu trabalho, geralmente notifica o componente mediador.<\/p>\n

    \"\"<\/p>\n

    Os componentes executores comunicam-se apenas com o componente mediador, nunca com outros componentes executores. Enquanto isso,\u00a0os componentes mediadores s\u00e3o a “fonte da verdade” com rela\u00e7\u00e3o ao est\u00e1gio de execu\u00e7\u00e3o de um fluxo para tratamento de um evento.<\/p>\n

    De maneira concreta, quando o mediador exerce fun\u00e7\u00e3o ativa, direcionado o workflow<\/em>, muitas vezes comunica-se enviando comandos para os diversos processadores.<\/p>\n

    \"\"<\/p>\n

    Geralmente, aplica\u00e7\u00f5es com arquiteturas event-driven<\/em> desenvolvidas nessa abordagem t\u00eam diversos componentes mediadores, algumas vezes, agrupados processos correlatos, outras vezes, ponderando estrat\u00e9gias para atender atributos de qualidade como disponibilidade, elasticidade e performance.<\/p>\n

    Mediadores podem ser implementados em c\u00f3digo puro ou utilizando tecnologias como Apache Camel<\/a> e Mule ESB<\/a> ou Apache ODE<\/a>. H\u00e1 tamb\u00e9m quem defenda a utiliza\u00e7\u00e3o de ferramentas BPM (e BPA).<\/p>\n