{"id":1265,"date":"2021-04-13T13:56:06","date_gmt":"2021-04-13T16:56:06","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=1265"},"modified":"2024-01-11T17:55:02","modified_gmt":"2024-01-11T20:55:02","slug":"capitulo-01-v1-02","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/","title":{"rendered":"Cap\u00edtulo 01 v1.02"},"content":{"rendered":"Se nenhum homem \u00e9 uma ilha, tampouco qualquer artefato de software relevante ser\u00e1!<\/strong> Afinal, todo software suporta a execu\u00e7\u00e3o de uma ou mais atividades que s\u00e3o partes de um ou mais processos, sempre com etapas anteriores e posteriores que, provavelmente, por sua vez, tamb\u00e9m s\u00e3o suportadas por outros agentes (software ou n\u00e3o). De alguma forma, as informa\u00e7\u00f5es de um software que suporta uma atividade precisam ser “levadas” para outro que suportar\u00e1 a pr\u00f3xima atividade.\n
\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

\n

Aplicativos interessantes raramente operam isolados. Quer seu aplicativo de vendas deva interagir com seu aplicativo de estoque, seu aplicativo de compras deva se conectar a um site de leil\u00e3o ou seu PDA precise sincronizar com o servidor de calend\u00e1rio corporativo, parece que qualquer aplicativo pode ser melhor integrando-o com outros aplicativos. (HOHPE; WOOLF, 2003)<\/em><\/p>\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

\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. Uma falha em um componente faz com que a carga seja redistribu\u00edda para seus pares e introduz atrasos e estresse para seus chamadores. Esse aumento de estresse torna extremamente prov\u00e1vel que outro componente do sistema falhe. Isso, por sua vez, torna a pr\u00f3xima falha mais prov\u00e1vel, resultando eventualmente em colapso total. (Nygard)<\/em><\/p>\nPor tudo isso, explicitar e tratar adequadamente integra\u00e7\u00f5es \u00e9 tarefa fundamental nas boas pr\u00e1ticas de arquitetura de software.<\/strong> Ali\u00e1s, o mapeamento precoce das integra\u00e7\u00f5es ajuda a identificar mais rapidamente os objetivos do neg\u00f3cio, restri\u00e7\u00f5es e atributos de qualidade.<\/strong>\n

\n

Explicitando as rela\u00e7\u00f5es de um software com outros<\/h2>\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.\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

\n

Embora esta seja 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

Representando relacionamentos usando o modelo C4<\/h2>\nNos \u00faltimos anos, uma nota\u00e7\u00e3o tem ganhado destaque para documenta\u00e7\u00e3o de relacionamentos. Trata-se do modelo C4, idealizado por Simon Brown.\n
\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. (Wikipedia)<\/em><\/p>\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

Depois de entender como seu sistema se encaixa no ambiente geral de TI, uma pr\u00f3xima etapa realmente \u00fatil \u00e9 ampliar o limite do sistema com um diagrama de cont\u00eainer. Um “cont\u00eainer” \u00e9 algo como um aplicativo da web do lado do servidor, aplicativo de p\u00e1gina \u00fanica, aplicativo de desktop, aplicativo m\u00f3vel, esquema de banco de dados, sistema de arquivos, etc. Essencialmente, um cont\u00eainer \u00e9 uma unidade execut\u00e1vel\/implement\u00e1vel separadamente (por exemplo, um espa\u00e7o de processo separado) que executa c\u00f3digo ou armazena dados.<\/em><\/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. (Simon Brown)<\/em><\/p>\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 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

Principais abordagens para integra\u00e7\u00e3o entre aplica\u00e7\u00f5es<\/h2>\nAo longo dos anos, a integra\u00e7\u00e3o entre sistemas \u00e9 implementada utilizando uma das seguintes quatro abordagens:\n
\n
    \n
  1. Troca de arquivos\u00a0<\/strong>– Onde uma ou mais aplica\u00e7\u00f5es escrevem arquivos em um determinado formato que ser\u00e3o, posteriormente, processados por outra. Al\u00e9m do formato, \u00e9 necess\u00e1rio estabelecer regras para como nomear os arquivos e onde estes devem ser salvos.<\/li>\n
  2. Banco de dados compartilhado\u00a0<\/strong>– com m\u00faltiplas aplica\u00e7\u00f5es compartilhando um mesmo esquema, localizado em um \u00fanico banco. N\u00e3o h\u00e1, de fato, duplica\u00e7\u00e3o de dados e tampouco transfer\u00eancias.<\/li>\n
  3. RPC<\/strong>, onde uma aplica\u00e7\u00e3o exp\u00f5e algumas de suas funcionalidades, geralmente atrav\u00e9s de servi\u00e7os e protocolos abertos, de forma que estas possam ser acessadas por outra aplica\u00e7\u00e3o. A comunica\u00e7\u00e3o \u00e9 geralmente s\u00edncrona.<\/li>\n
  4. Mensageria<\/strong>, onde uma aplica\u00e7\u00e3o publica mensagens para um canal comum para serem processadas por outras aplica\u00e7\u00f5es que “escutam” ativamente o canal.<\/li>\n<\/ol>\n
    \n

    Tamb\u00e9m h\u00e1 as integra\u00e7\u00f5es manuais, ou seja, pelo “estagi\u00e1rio digitador” que, partindo de um relat\u00f3rio, gera entradas em sistemas.<\/p>\nMuito embora todas as quatro abordagens resolvam essencialmente os mesmos problemas, cada uma delas tem vantagens e desvantagens. N\u00e3o raro, ali\u00e1s, mais de uma abordagem \u00e9 empregada em um software.\n

    Desafios comuns em integra\u00e7\u00f5es<\/h2>\nTodas as integra\u00e7\u00f5es tendem a enfrentar os seguintes desafios comuns:\n
    \n
      \n
    1. Rede n\u00e3o confi\u00e1vel e lenta<\/strong> – Como bem descrito pelas “oito fal\u00e1cias da computa\u00e7\u00e3o distribu\u00edda”, a rede n\u00e3o pode ser assumida como confi\u00e1vel, tampouco livre de penalidades. N\u00e3o \u00e9 raro que aplica\u00e7\u00f5es que precisam ser integradas est\u00e3o operando geograficamente distantes.<\/li>\n
    2. Toda aplica\u00e7\u00e3o \u00e9 diferente (e \u00fanica)<\/strong> – Solu\u00e7\u00f5es de integra\u00e7\u00e3o precisam transmitir informa\u00e7\u00f5es entre sistemas escritos em linguagens de programa\u00e7\u00e3o, plataformas operacionais e formatos diferentes. Nem sempre, essa passagem \u00e9 f\u00e1cil.<\/li>\n
    3. Mudan\u00e7a \u00e9 inevit\u00e1vel\u00a0<\/strong>– Aplica\u00e7\u00f5es sempre mudam ao longo do tempo (ali\u00e1s, esse \u00e9 o grande desafio das disciplinas de engenharia). Qualquer solu\u00e7\u00e3o de integra\u00e7\u00e3o precisa permanecer alinhada com essas mudan\u00e7as.<\/li>\n<\/ol>\n
      \n

      As falhas da rede implicam em adotar diversas estrat\u00e9gias, incluindo chamadas idempotentes,\u00a0handshakes<\/em>, pol\u00edticas de retentativa e\u00a0circuit-breakers<\/em>.<\/p>\n

      Para integra\u00e7\u00f5es com servi\u00e7os externos, surgem quest\u00f5es relacionadas a versionamento de APIs e continuidades.<\/p>\n

      A lei de Hyrum<\/h2>\nInteressante observar que, na pr\u00e1tica, nem todas as integra\u00e7\u00f5es de um software nascem com a anu\u00eancia do time que o desenvolve.<\/strong> N\u00e3o raro, relacionamentos s\u00e3o estabelecidos com base em caracter\u00edsticas n\u00e3o documentadas de aplica\u00e7\u00f5es ocasionando em dificuldades para a evolu\u00e7\u00e3o. Essa realidade \u00e9 retratada por Hyrum Wright<\/a>, engenheiro da Google, em uma \u201clei\u201d de engenharia de software que leva seu nome<\/a>.\n
      \n

      Com um n\u00famero suficiente de usu\u00e1rios, n\u00e3o importa o que estiver acertado em contrato: todos os comportamentos observ\u00e1veis de um sistema ser\u00e3o premissas para funcionamento de outros artefatos. (Hyrum Wright)<\/em><\/p>\n

      Tal realidade \u00e9 t\u00e3o frequente que foi “piada” no xkcd<\/a>.<\/p>\n

      \"\"<\/p>\n

      Detalhes t\u00e9cnicos de implementa\u00e7\u00e3o como tempos de resposta, ordena\u00e7\u00e3o em resultados, esquemas de bancos de dados, mecanismos de persist\u00eancia e, at\u00e9 mesmo, detalhes de infraestrutura de uma aplica\u00e7\u00e3o servem, invariavelmente, como fundamento para desenvolvimento de processos e outros sistemas.<\/p>\n

      Esquemas de banco de dados, por exemplo, mesmo que oficialmente privados e restritos aos times t\u00e9cnicos da organiza\u00e7\u00e3o desenvolvedora, s\u00e3o frequentemente utilizados para desenvolvimento de mecanismos de integra\u00e7\u00e3o.<\/p>\nQuanto maior o n\u00famero de usu\u00e1rios de um software, maiores s\u00e3o as possibilidades de clientes precisarem permanecer em vers\u00f5es antigas.<\/i>\u00a0<\/strong>Afinal, estes clientes poder\u00e3o ter constru\u00eddo processos e ferramentas usando como base comportamentos do sistema que n\u00e3o foram preservados em vers\u00f5es mais novas. A consequ\u00eancia direta disso \u00e9 o aumento dos custos da empresa desenvolvedora pela necessidade de manter suporte a vers\u00f5es legadas, mesmo sem gerar valor novo.\n

      \n

      Toda grande jornada tem um primeiro passo\u2026<\/h2>\n

      As decis\u00f5es de design que se relacionam com a arquitetura garantem o atendimento dos objetivos do neg\u00f3cio, respeitando restri\u00e7\u00f5es e atingindo atributos de qualidade.\u00a0<\/strong>N\u00e3o raro, todos estes elementos tem rela\u00e7\u00e3o direta com os relacionamentos do software que est\u00e1 sendo arquitetado no ambiente que ir\u00e1 operar.<\/p>\n

      Quanto antes os respons\u00e1veis pela elabora\u00e7\u00e3o da arquitetura desenvolverem familiaridade com as integra\u00e7\u00f5es que ir\u00e3o ser suportadas, maiores as chances de sucesso!<\/strong> Por isso, a recomenda\u00e7\u00e3o \u00e9 explicitar essas integra\u00e7\u00f5es no in\u00edcio do esfor\u00e7o de desenvolvimento. Al\u00e9m disso, garantir que os artefatos de documenta\u00e7\u00e3o gerados se mantenham atualizados.<\/p>\n

      Explicitar as integra\u00e7\u00f5es do software s\u00e3o uma boa forma de integrar novos desenvolvedores ao time de trabalho.<\/p>\n

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

      Antes de avan\u00e7ar para o pr\u00f3ximo cap\u00edtulo recomendo as seguintes atividades:<\/p>\n

        \n
      • Utilizando o modelo C4, desenvolva representa\u00e7\u00f5es do software que est\u00e1 desenvolvendo nos n\u00edveis de contexto e cont\u00eainer.<\/li>\n
      • Pondere sobre quais abordagens de integra\u00e7\u00e3o est\u00e3o sendo utilizadas atualmente. Quais as “dores” percebidas nas escolhas feitas?<\/li>\n
      • Reflita sobre a lei de Hyrum e o software que est\u00e1 desenvolvendo. H\u00e1 ind\u00edcios de integra\u00e7\u00f5es desenvolvidas “apesar” das especifica\u00e7\u00f5es?<\/li>\n<\/ul>\n","protected":false},"featured_media":1243,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[],"sessoes":[57],"apendices":[],"capitulos":[14],"class_list":["post-1265","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","sessoes-secao-1","capitulos-capitulo-1-2"],"acf":[],"yoast_head":"\nCap\u00edtulo 01 v1.02 - 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\/capitulo-01-v1-02\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Cap\u00edtulo 01 v1.02 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"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. 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 […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/\" \/>\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-11T20:55:02+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/tom-winckels-I7oLRdM9YIw-unsplash.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"681\" \/>\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=\"11 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\/capitulo-01-v1-02\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/\",\"name\":\"Cap\u00edtulo 01 v1.02 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/tom-winckels-I7oLRdM9YIw-unsplash.jpg\",\"datePublished\":\"2021-04-13T16:56:06+00:00\",\"dateModified\":\"2024-01-11T20:55:02+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/tom-winckels-I7oLRdM9YIw-unsplash.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/tom-winckels-I7oLRdM9YIw-unsplash.jpg\",\"width\":1024,\"height\":681},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#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\u00edtulo 01 v1.02\"}]},{\"@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\u00edtulo 01 v1.02 - 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\/capitulo-01-v1-02\/","og_locale":"pt_BR","og_type":"article","og_title":"Cap\u00edtulo 01 v1.02 - Manual do Arquiteto de Software","og_description":"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. 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 […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-11T20:55:02+00:00","og_image":[{"width":1024,"height":681,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/tom-winckels-I7oLRdM9YIw-unsplash.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"11 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/","name":"Cap\u00edtulo 01 v1.02 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/tom-winckels-I7oLRdM9YIw-unsplash.jpg","datePublished":"2021-04-13T16:56:06+00:00","dateModified":"2024-01-11T20:55:02+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/tom-winckels-I7oLRdM9YIw-unsplash.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/tom-winckels-I7oLRdM9YIw-unsplash.jpg","width":1024,"height":681},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/capitulo-01-v1-02\/#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\u00edtulo 01 v1.02"}]},{"@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\/1265","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=1265"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/1243"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=1265"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=1265"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=1265"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=1265"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=1265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}