{"id":3873,"date":"2023-10-23T10:48:07","date_gmt":"2023-10-23T13:48:07","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=3873"},"modified":"2026-04-27T17:21:33","modified_gmt":"2026-04-27T20:21:33","slug":"integrando-sistemas-de-software","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/integrando-sistemas-de-software\/","title":{"rendered":"Cap 1.2 Integrando sistemas de software"},"content":{"rendered":"

Dificilmente um software conseguir\u00e1 atender sozinho todas as demandas de seu contexto de opera\u00e7\u00e3o<\/strong>. Por essa raz\u00e3o, para cumprir, de fato, os objetivos do neg\u00f3cio, a arquitetura de um software dever\u00e1 contemplar, al\u00e9m dele pr\u00f3prio, a rela\u00e7\u00e3o com os demais “integrantes sist\u00eamicos”, delimitando responsabilidades e relacionamentos.<\/p>\n

Sabendo\u00a0que, por exemplo, um software digitaliza ou suporta a execu\u00e7\u00e3o de atividades de um processo, ser\u00e1 mais bem sucedido aquele que, necess\u00e1rio para uma atividade, “conseguir passar o bast\u00e3o” para os demais, necess\u00e1rios para as demais atividades.<\/p>\n

\"\"<\/p>\n

Segregando responsabilidades, um software gerencial ser\u00e1 bem sucedido se conseguir “consolidar dados” de diversas fontes transacionais.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Data is a precious thing and will last longer than the systems themselves.<\/em>\r\n

Tim Berners-Lee<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

\"\"<\/p>\n

Finalmente, um software especialista, para ser “bem sucedido”, precisar\u00e1 estar “dispon\u00edvel” para acionamento f\u00e1cil.<\/p>\n

\"\"<\/p>\n

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

Archimate (R) 3.1 Specification<\/p>\r\nA linguagem ArchiMate permite que arquitetos corporativos descrevam, analisem e visualizem os relacionamentos entre os dom\u00ednios de neg\u00f3cios de maneira efetiva.<\/p>\n

Este livro \u00e9 a especifica\u00e7\u00e3o oficial da linguagem de modelagem ArchiMate 3.1 do The Open Group.\r\n

Acessar livro<\/a><\/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\"\" Habitue-se a utilizar, consistentemente e corretamente, linguagens visuais de modelagem, como ArchiMate e C4, para comunicar aspectos relevantes de arquitetura. <\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A rela\u00e7\u00e3o de um software com artefatos externos \u00e9, ao mesmo tempo, a express\u00e3o de sua utilidade e a principal fonte de problemas em ambiente produtivo. <\/strong>Sejam as integra\u00e7\u00f5es expl\u00edcitas, com esfor\u00e7o de desenvolvimento do time para fazer com que ela aconte\u00e7a, ou impl\u00edcitas, acontecendo a revelia e gerando apenas dificuldade para evolu\u00e7\u00e3o, as integra\u00e7\u00f5es s\u00e3o aspecto cr\u00edtico da arquitetura de qualquer software.<\/p>\n

Quando as integra\u00e7\u00f5es n\u00e3o s\u00e3o devidamente projetadas, acontecem “organicamente”, muitas vezes como iniciativas shadow IT.\u00a0<\/em>Obviamente, esse \u00e9 um\u00a0bad smell<\/em> para o futuro da solu\u00e7\u00e3o como um todo.<\/p>\nQuanto mais relacionamentos um software possuir, maior ser\u00e1 seu impacto e relev\u00e2ncia no contexto onde funciona. Em termos simples, software com poucos relacionamentos costuma ser in\u00fatil ou ser importante apenas em per\u00edodos curtos e eventuais<\/strong>. N\u00e3o \u00e9 exagero dizer que qualidade “interna” de um software pouco importar\u00e1 se suas “integra\u00e7\u00f5es” n\u00e3o forem bem-sucedidas no m\u00e9dio\/longo prazo.\n

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

Aplicativos interessantes raramente operam isolados.<\/em><\/p>\n

\r\n

Hohpe e Woolf<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nBoa parte dos problemas em ambiente produtivo ocorrem por defici\u00eancias no tratamento de falhas de integra\u00e7\u00e3o entre sistemas.<\/strong> N\u00e3o raro, sistemas de\u00a0e-commerce,<\/em> por exemplo, apresentam instabilidades por falhas na integra\u00e7\u00e3o com o sistema banc\u00e1rio que viabiliza a cobran\u00e7a ou, ainda, devido a problemas para acessar o invent\u00e1rio.\n

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

O acoplamento forte permite que as “rachaduras” em uma parte do sistema se propaguem – ou se multipliquem – atrav\u00e9s das camadas ou limites do subsistema.\u00a0<\/em><\/p>\n

\r\n

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

Aspectos arquiteturais relevantes em integra\u00e7\u00f5es<\/h2>\n

Ao analisar a integra\u00e7\u00e3o entre dois ou mais sistemas de software \u00e9 importante analisar tr\u00eas aspectos: forma de comunica\u00e7\u00e3o, necessidade de consist\u00eancia e coordena\u00e7\u00e3o.<\/strong><\/p>\n

\"\"<\/p>\n

Come\u00e7ando pela forma de comunica\u00e7\u00e3o, chegamos a duas possibilidades gen\u00e9ricas: s\u00edncrona e ass\u00edncrona.<\/strong>\u00a0Dois sistemas de software tem comunica\u00e7\u00e3o s\u00edncrona<\/span> quando a requisi\u00e7\u00e3o de uma das partes implica em um tempo espera at\u00e9 que uma resposta seja devolvida (atualiza\u00e7\u00e3o de status ou indicativo de erro). Por outro lado, a comunica\u00e7\u00e3o \u00e9 ass\u00edncrona<\/span> quando a parte requisitante prossegue trabalho ap\u00f3s confirma\u00e7\u00e3o m\u00ednima de que sua solicita\u00e7\u00e3o foi aceta.<\/p>\n

As decis\u00f5es arquiteturais que dizem respeito ao formato de comunica\u00e7\u00e3o entre sistemas tem impacto direto em atributos de qualidade como seguran\u00e7a, resili\u00eancia, escalabilidade e desempenho.<\/strong><\/p>\n

Tratando de consist\u00eancia h\u00e1, tamb\u00e9m, duas possibilidades gen\u00e9ricas: atomicidade ou eventualidade<\/strong>, sendo que, dois sistemas de software tem consist\u00eancia at\u00f4mica quando, em hip\u00f3tese alguma, seus estados refletem momentos diferentes (tudo est\u00e1 atualizado ou nada est\u00e1 atualizado). Por outro lado, \u00a0dois sistemas tem consist\u00eancia eventual quando defasagens sejam suportadas sem preju\u00edzo de opera\u00e7\u00e3o.<\/p>\n

Em sistemas distribu\u00eddos, dificilmente se atinge indicadores adequados de escalabilidade e resili\u00eancia quando atomicidade \u00e9 indispens\u00e1vel.<\/strong><\/p>\n

Finalmente, tratando de coordena\u00e7\u00e3o h\u00e1, tamb\u00e9m, duas possibilidades gen\u00e9ricas: coreografia ou orquestra\u00e7\u00e3o<\/strong>, sendo que, dois sistemas de software ser\u00e3o “coreografados” quando n\u00e3o dependerem de um agente externo (um terceiro software) para garantir que a integra\u00e7\u00e3o aconte\u00e7a. Entretanto, h\u00e1 cen\u00e1rios com\u00a0workflows\u00a0<\/em>complexos – envolvendo diversas etapas – onde algum tipo de orquestra\u00e7\u00e3o torna-se indispens\u00e1vel.<\/p>\n

Cabe ao arquiteto decidir, para cada integra\u00e7\u00e3o, se a comunica\u00e7\u00e3o ser\u00e1 s\u00edncrona ou ass\u00edncrona, a consist\u00eancia dever\u00e1 ser at\u00f4mica ou eventual e, finalmente, a coordena\u00e7\u00e3o ocorrer\u00e1 por coreografia.<\/strong><\/p>\n

Integra\u00e7\u00e3o simples ou colabora\u00e7\u00e3o<\/h2>\n

Eventualmente, integra\u00e7\u00f5es tem regras e formatos que extrapolam as “responsabilidades” de cada um dos sistemas, individualmente, expressando funcionalidades in\u00e9ditas resultantes de uma “colabora\u00e7\u00e3o”.<\/strong><\/p>\n

Considere, por exemplo, uma organiza\u00e7\u00e3o pode desejar implementar suporte especial para o atendimento a revendedores, combinando funcionalidades de seus sistema de CRM e \u00a0ERP – nenhum deles planejado, originalmente, para essa finalidade.<\/p>\n

\"\"<\/p>\n

A integra\u00e7\u00e3o desses sistemas ser\u00e1 uma colabora\u00e7\u00e3o que, provavelmente, envolver\u00e1 a escrita de c\u00f3digo novo.<\/p>\n

\"\"<\/p>\n

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

Modelando 'colabora\u00e7\u00f5es' entre aplica\u00e7\u00f5es<\/p>\r\n

Manual do Arquiteto Corporativo<\/p>\r\n<\/p>\n

A modelagem de colabora\u00e7\u00f5es entre aplica\u00e7\u00f5es \u00e9 atividade essencial na pr\u00e1tica da arquitetura corporativa. Neste cap\u00edtulo, apresento ideias e conceitos que colaboram nessa atividade.<\/p>\n

\r\n

Ler cap\u00edtulo<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Explicitando as rela\u00e7\u00f5es de um software com outros usando C4<\/h2>\n

Nos \u00faltimos anos, uma nota\u00e7\u00e3o tem ganhado destaque para documenta\u00e7\u00e3o de relacionamentos. Trata-se do modelo C4, idealizado por Simon Brown.<\/p>\n

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

O modelo C4 \u00e9 uma t\u00e9cnica de nota\u00e7\u00e3o gr\u00e1fica enxuta para modelar a arquitetura de sistemas de software. \u00c9 baseado em uma decomposi\u00e7\u00e3o estrutural de um sistema em cont\u00eaineres e componentes e depende de t\u00e9cnicas de modelagem existentes, como a Unified Modeling Language (UML) ou Entity Relation Diagrams (ERD) para a decomposi\u00e7\u00e3o mais detalhada dos blocos de constru\u00e7\u00e3o arquitet\u00f4nicos.<\/em><\/p>\n

\r\n

Wikipedia<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nEm uma primeira an\u00e1lise da arquitetura de um software podemos assumir que este, em um contexto amplo, \u00e9 um componente, com determinadas responsabilidades, que se relaciona com outros componentes, os demais agentes, tamb\u00e9m com responsabilidades mais ou menos delimitadas. Essa \u00e9 a proposta do diagrama de contextos, o primeiro n\u00edvel do modelo C4\n

\n

\"\"<\/p>\n

\n

O prop\u00f3sito dessa an\u00e1lise \u00e9 revelar quem s\u00e3o as “pessoas” (usu\u00e1rios, agentes, pap\u00e9is ou personas) e outros artefatos (depend\u00eancias externas) que est\u00e3o diretamente conectadas com o software que estamos analisando. Geralmente, estes outros sistemas est\u00e3o fora do escopo prim\u00e1rio.<\/p>\nAgentes externos podem operar como gatilhos para opera\u00e7\u00f5es no software ou como fontes de dados. Outras vezes, ser\u00e3o “acionados” pelo sistemas que estamos analisando ou ir\u00e3o ser atualizados por este. Finalmente, podem ser utilit\u00e1rios realizando opera\u00e7\u00f5es de alta especificidade ou complexidade tecnol\u00f3gica (como o envio massivo de e-mails).\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" De todas as pr\u00e1ticas associadas a arquitetura de software, a mais fundamental \u00e9 a explicita\u00e7\u00e3o das integra\u00e7\u00f5es que precisam ser suportadas por um sistema de software.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Embora esta seja uma an\u00e1lise muito simples, na pr\u00e1tica, sua execu\u00e7\u00e3o tem se relevando \u00fatil e desafiadora.<\/strong> Por incr\u00edvel que pare\u00e7a, \u00e9 dif\u00edcil para as organiza\u00e7\u00f5es relacionar quais s\u00e3o os principais \u201cacionadores\u201d e \u201cacionados\u201d para os diversos sistemas. Tamb\u00e9m costuma ser bem dif\u00edcil criar uma descri\u00e7\u00e3o sucinta sobre o que um sistema faz ou deveria fazer.<\/p>\n

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

Visualising software architecture with the C4 model<\/p>\r\nNa palestra de Simon Brown na AOTB 2019, ele explora a comunica\u00e7\u00e3o visual da arquitetura de software com base em uma d\u00e9cada de experi\u00eancias trabalhando com equipes de desenvolvimento de software grandes e pequenas em todo o mundo.\r\n

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

Representando relacionamentos usando C4<\/h2>\n

O n\u00edvel mais alto de abstra\u00e7\u00e3o proposto pelo modelo C4 prop\u00f5e a elabora\u00e7\u00e3o de diagramas de contexto, muito semelhantes ao que indicamos aqui. J\u00e1 no segundo n\u00edvel, o diagrama de cont\u00eaineres, “explode” o sistema que sendo analisado para revelar sua estrutura.<\/p>\n

\"\"<\/p>\n

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

O diagrama do cont\u00eaineres mostra a forma de alto n\u00edvel da arquitetura do software e como as responsabilidades s\u00e3o distribu\u00eddas por ela. Tamb\u00e9m mostra as principais op\u00e7\u00f5es de tecnologia e como os cont\u00eaineres se comunicam. \u00c9 um diagrama simples e focado em tecnologia de alto n\u00edvel, \u00fatil para desenvolvedores de software e equipes de suporte\/opera\u00e7\u00f5es.<\/em><\/p>\n

\r\n

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

A elabora\u00e7\u00e3o do diagrama de cont\u00eaineres n\u00e3o \u00e9 tarefa trivial.<\/p>\n

Em sistemas muito grandes, ou legados, \u00e9 comum que n\u00e3o seja evidente a responsabilidade de cada cont\u00eainer (indicando claro acoplamento). Em sistemas novos ou em desenvolvimento, h\u00e1 uma tend\u00eancia de simplificar em demasia os cont\u00eaineres.<\/p>\n

O diagrama do cont\u00eaineres mostra a forma de alto n\u00edvel da arquitetura do software e como as responsabilidades s\u00e3o distribu\u00eddas por ela. Tamb\u00e9m mostra as principais op\u00e7\u00f5es de tecnologia e como os cont\u00eaineres se comunicam. \u00c9 um diagrama simples e focado em tecnologia de alto n\u00edvel, \u00fatil para desenvolvedores de software e equipes de suporte\/opera\u00e7\u00f5es.<\/em><\/p>\n

[\/sc]<\/p>\n

O maior ganho que tenho percebido na elabora\u00e7\u00e3o desse diagrama est\u00e1 na explicita\u00e7\u00e3o da complexidade dos sistemas, geralmente causada por um projeto descuidado ou pela evolu\u00e7\u00e3o descontrolada.<\/strong> Para sistemas novos, esse diagrama antecipa discuss\u00f5es que ficariam relegadas a momentos posteriores e que, se feitas no momento certo, poderiam evitar dores de cabe\u00e7a.<\/p>\n

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

Software Architecture for Developers - Volume 2<\/p>\r\nSimon Brown explica nos dois volumes de “Software Architecture for Developers” ideias essenciais relacionadas a arquitetura de software e a utiliza\u00e7\u00e3o do modelo C4.\r\n

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

Modelando depend\u00eancias de microsservi\u00e7os com C4<\/h2>\n

Estrat\u00e9gias arquiteturais baseadas em microsservi\u00e7os representam desafios para mapeamento de depend\u00eancias. O problema \u00e9 que, embora a rela\u00e7\u00e3o entre dois microsservi\u00e7os se assemelhe a rela\u00e7\u00e3o de qualquer outro n\u00edvel de sistema, a granularidade dificulta visualiza\u00e7\u00e3o e entendimento.<\/p>\n

Simon Brown, criador do modelo C4 ensina que h\u00e1 duas abordagens comuns para modelagem de microsservi\u00e7os com o modelo C4:<\/p>\n