{"id":1390,"date":"2021-04-23T15:14:55","date_gmt":"2021-04-23T18:14:55","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=1390"},"modified":"2024-01-11T18:09:40","modified_gmt":"2024-01-11T21:09:40","slug":"software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/","title":{"rendered":"Software relevante evolui&#8230; e a arquitetura precisa suportar isso! \/ Cap\u00edtulo 3 v1.00"},"content":{"rendered":"<p><strong>Software relevante evolui!<\/strong> Seja para atender novas demandas do neg\u00f3cio, seja para incorporar novidades tecnol\u00f3gicas, adapta\u00e7\u00f5es s\u00e3o sempre necess\u00e1rias. Enquanto isso, \u00e9 fato que modificar software fica, geralmente, mais dif\u00edcil com o tempo.<\/p>\n<p style=\"padding-left: 40px;\"><em>Apesar de nossos melhores esfor\u00e7os, o software se torna mais dif\u00edcil de alterar com o tempo. Por uma variedade de raz\u00f5es, as partes que comp\u00f5em os sistemas de software desafiam a modifica\u00e7\u00e3o f\u00e1cil, tornando-se mais fr\u00e1geis e intrat\u00e1veis com o tempo. Mudan\u00e7as em projetos de software s\u00e3o geralmente conduzidas pela reavalia\u00e7\u00e3o da funcionalidade e\/ou escopo. (Ford, Parsons e Kua)<\/em><\/p>\n<strong>As mudan\u00e7as, seja nos neg\u00f3cios ou na tecnologia, acontecem em um ritmo cada vez mais acelerado. O software precisa evoluir em um ritmo compat\u00edvel com essas mudan\u00e7as, caso contr\u00e1rio, se tornar\u00e1 irrelevante r\u00e1pido, precisando ser substitu\u00eddo.<\/strong> Ainda pior, eventualmente, &#8220;trocar&#8221; de software n\u00e3o \u00e9 uma op\u00e7\u00e3o &#8211; nesses casos, o preju\u00edzo \u00e9 mais grave e pode ser irrepar\u00e1vel.\n<hr \/>\nPor tudo isso, <strong><em>Evolvability<\/em> \u00e9 um importante atributo de qualidade para qualquer boa arquitetura, sen\u00e3o o mais importante.<\/strong>\n<hr \/>\n<p><img decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/imgs.xkcd.com\/comics\/fixing_problems.png\" alt=\"Fixing Problems\" \/><\/p>\n<h2>As leis de Lehman<\/h2>\n<p>Ao longo de d\u00e9cadas, <a href=\"https:\/\/pt.wikipedia.org\/wiki\/Meir_M._Lehman\">Meir Lehman<\/a> e <a href=\"https:\/\/en.wikipedia.org\/wiki\/L%C3%A1szl%C3%B3_B%C3%A9l%C3%A1dy\">L\u00e1szl\u00f3 B\u00e9l\u00e1dy<\/a> formularam, propuseram e aprimoraram diversas \u201cleis\u201d que, alegadamente, governam a evolu\u00e7\u00e3o de sistemas de software. Essas leis ficaram conhecidas como \u201cLeis de Lehman\u201d.<\/p>\nAs \u201cLeis de Lehman\u201d descrevem e ajudam a entender o sens\u00edvel equil\u00edbrio entre as motiva\u00e7\u00f5es para a evolu\u00e7\u00e3o de um software, por adapta\u00e7\u00f5es, e as causas para o aumento da complexidade (em consequ\u00eancia, do lead time para atender demandas do neg\u00f3cio) ao longo do tempo.\n<hr \/>\n<p><strong>As duas primeiras \u201cleis\u201d formuladas por eles, em 1974, foram a lei da \u201cmudan\u00e7a cont\u00ednua\u201d e a lei da \u201ccomplexidade crescente\u201d.<\/strong> A primeira diz que, ao longo do tempo, um sistema de software precisa ser continuamente adaptado, recebendo novas \u201cadapta\u00e7\u00f5es\u201d, para se manter relevante e satisfat\u00f3rio. A segunda aponta que, enquanto essas \u201cadapta\u00e7\u00f5es\u201d s\u00e3o feitas, o software se torna mais complexo, exceto quando existam esfor\u00e7os explicitamente direcionados para mitigar essa complexidade.<\/p>\n<p><img fetchpriority=\"high\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/pt-static.z-dn.net\/files\/d4d\/8804b98edc0f3dbca971166f297927f0.jpg\" alt=\"Qual \u00e9 a rela\u00e7\u00e3o existente entre a imagem e o texto da charge? - Brainly.com.br\" width=\"489\" height=\"283\" \/><\/p>\n<p>As duas leis, deliciosamente evidentes e conflitantes, levam a alguns desdobramentos preocupantes:<\/p>\n<ul>\n<li>Projetos de software bem sucedidos est\u00e3o \u201ccondenados\u201d a demandarem trabalho para mitigar a a complexidade.<\/li>\n<li>Times extremamente eficazes, mas exclusivamente focados em atender as demandas de neg\u00f3cio se tornam, eventualmente, menos produtivos, deteriorando sua capacidade de fazer entregas e, consequentemente, sua efic\u00e1cia.<\/li>\n<li>O esfor\u00e7o para combater a complexidade \u00e9 imperativo para manter o software relevante no m\u00e9dio\/longo prazo.<i class=\"i-twitter\"><\/i><\/li>\n<li>Times de neg\u00f3cio que n\u00e3o se sensibilizam para a necessidade de reduzir a complexidade do software, priorizando somente inclus\u00e3o de features, se condenam a ter suas demandas atendidas em prazos cada vez maiores.<\/li>\n<\/ul>\n<hr \/>\n<h2>Mudan\u00e7as tecnol\u00f3gicas acontecem rapidamente e t\u00eam impactos imprevis\u00edveis<\/h2>\nO conjunto de tecnologias, t\u00e9cnicas, padr\u00f5es e boas pr\u00e1ticas para desenvolver software s\u00e3o din\u00e2micas e inst\u00e1veis. Essa instabilidade, ali\u00e1s, \u00e9 um dos principais desafios para manter e evoluir sistemas.\n<hr \/>\n<p>A emerg\u00eancia de pr\u00e1ticas como a utiliza\u00e7\u00e3o de cont\u00eainers, aceleradas por tecnologias como Docker, por exemplo, impactam a ind\u00fastria de forma definitiva e, para os menos \u201cantenados\u201d, parece surgir de uma hora para outra.<\/p>\nLinguagens novas de programa\u00e7\u00e3o, mais expressivas (pelo menos para alguns dom\u00ednios) tamb\u00e9m surgem em ritmo cada vez mais acelerado. Recentemente, mesmo as linguagens consolidadas tamb\u00e9m passaram a receber atualiza\u00e7\u00f5es mais frequentes. Em consequ\u00eancia disso, bases de c\u00f3digo gigantes que geram sistemas em produ\u00e7\u00e3o, parecem cada vez mais \u201clegadas\u201d em prazos cada vez mais curtos.\n<hr \/>\n<p>Frameworks Javascript parecem crescer em popularidade e se tornarem obsoletas em ciclos, muitas vezes, menores do que os necess\u00e1rios para o desenvolvimentos de alguns grandes sistemas. Em poucos anos, vimos o decl\u00ednio de <a href=\"https:\/\/jquery.com\/\">jQuery<\/a>; a ascens\u00e3o e a \u201cmorte\u201d de <a href=\"https:\/\/angularjs.org\/\">AngularJS<\/a>; a \u201cprovoca\u00e7\u00e3o\u201d de <a href=\"https:\/\/backbonejs.org\/\">Backbone<\/a> e <a href=\"https:\/\/mustache.github.io\/\">Mustache<\/a>; o progresso com <a href=\"https:\/\/angular.io\/\">Angular<\/a>, <a href=\"https:\/\/pt-br.reactjs.org\/\">React<\/a> e <a href=\"https:\/\/vuejs.org\/\">Vue<\/a>; propostas ousadas multiplataforma como <a href=\"https:\/\/flutter.dev\/\">Flutter<\/a> e <a href=\"https:\/\/www.electronjs.org\/\">Electron<\/a>; etc. <strong>\u00c9 quase imposs\u00edvel dizer qual ser\u00e1 a tecnologia dominante para elabora\u00e7\u00e3o de <em>frontends<\/em> de aqui dois anos.<\/strong><\/p>\nN\u00e3o conseguimos predizer quando mudan\u00e7as impactantes do contexto de desenvolvimento ir\u00e3o ocorrer. Nem mesmo conseguimos antecipar quais ser\u00e3o \u201cpersistentes\u201d (se \u00e9 que essa palavra \u00e9 aplic\u00e1vel), entretanto, sabemos que mudan\u00e7as acontecem e o ritmo parece ser cada vez mais acelerado.\n<hr \/>\n<p style=\"padding-left: 40px;\"><em>Adicionar evolucionabilidade como uma caracter\u00edstica arquitet\u00f4nica implica proteger as outras caracter\u00edsticas conforme o sistema evolui. Por exemplo, se um arquiteto projetou uma arquitetura para escalabilidade, ele n\u00e3o sabe o que essa caracter\u00edstica degradar \u00e0 medida que o sistema evolui. Assim, a evolucionabilidade \u00e9 uma meta-caracter\u00edstica, um inv\u00f3lucro arquitet\u00f4nico que protege todas as outras caracter\u00edsticas arquitet\u00f4nicas. (Ford, Parsons e Kua)<\/em><\/p>\n<h2>O que \u00e9 arquitetura evolucion\u00e1ria<\/h2>\n<p>O conceito de arquitetura evolucion\u00e1ria foi consolidado no excelente livro <strong>Building Evolutionary Architectures<\/strong>, escrito por Neil Ford, Rebecca Parsons e Jason Kua. L\u00e1, eles prop\u00f5e que a<strong>rquiteturas evolucion\u00e1rias s\u00e3o aquelas que 1) suportam mudan\u00e7as incrementais guiadas; 2) em v\u00e1rias dimens\u00f5es.<\/strong> Partindo da defini\u00e7\u00e3o proposta, \u00e9 poss\u00edvel inferir que <strong>toda arquitetura evolucion\u00e1ria tem &#8220;<em>evolvability<\/em>&#8221; entre seus atributos de qualidade<\/strong>.<\/p>\nA escolha da palavra &#8220;evolucion\u00e1ria&#8221; \u00e9 bastante interessante. Ela se afasta, de certa forma, do conceito de &#8220;emerg\u00eancia&#8221;e de arquitetura emergente. Ou seja, n\u00e3o tem como lema desenvolver a arquitetura de maneira &#8220;desregrada&#8221;, simplesmente respondendo ao contexto de maneira desordenada. <strong>Assim, arquitetura evolucion\u00e1ria \u00e9 algo muito diferente de &#8220;n\u00e3o-arquitetura&#8221;, ou da &#8220;Arquitetura Zeca Pagodinho&#8221; (\ud83c\udfb6 deixa a vida me levar, vida leva eu! \ud83c\udfb5).<\/strong>\n<hr \/>\n<p><strong>A arquitetura evolucion\u00e1ria preconiza suportar as mudan\u00e7as, de maneira incremental.<\/strong> De maneira ampla, assume-se que a filosofia evolucion\u00e1ria defende que, sempre que poss\u00edvel, mudan\u00e7as devem ser aplicadas aos poucos, sem grandes saltos ou descontinuidades. Dessa forma, o &#8220;custo da mudan\u00e7a&#8221; fica dilu\u00eddo causando &#8220;menos dor&#8221;.<\/p>\n<p><img decoding=\"async\" class=\"wp-image-1432 aligncenter\" src=\"https:\/\/elemarjr.com\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/dor_mudanca.png\" alt=\"\" width=\"558\" height=\"301\" srcset=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/dor_mudanca.png 896w, https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/dor_mudanca-300x162.png 300w, https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/dor_mudanca-768x415.png 768w\" sizes=\"(max-width: 558px) 100vw, 558px\" \/><\/p>\n<p><strong>A evolu\u00e7\u00e3o incremental, para ser segura, precisa ser guiada! Quanto menos &#8220;guiada&#8221;, maior o risco. <\/strong>Ao longo do tempo, na medida em que as mudan\u00e7as ocorrem, \u00e9 importante que os compromissos da arquitetura de software sejam relembrados e reafirmados. A cada mudan\u00e7a, \u00e9 necess\u00e1rio identificar se houve aproxima\u00e7\u00e3o ou afastamento dos objetivos do neg\u00f3cio, se as restri\u00e7\u00f5es continuam sendo observadas e se os atributos de qualidade est\u00e3o sendo observados. Esse &#8220;cuidado&#8221; precisa ocorrer de forma objetiva e, sempre que poss\u00edvel, automatizada ou, pelo menos, incorporada a rotina. A proposta central passa por definir\u00a0<em>architectural fitness functions<\/em>.<\/p>\n<p>Finalmente, a arquitetura evolucion\u00e1ria lida com m\u00faltiplas dimens\u00f5es, tentando preservar o equil\u00edbrio. Melhorias na performance n\u00e3o podem comprometer a disponibilidade ou a seguran\u00e7a, por exemplo.<strong> A vis\u00e3o arquitetural \u00e9, dessa forma, hol\u00edstica.<\/strong><\/p>\n<p><strong>A <em>evolvability\u00a0<\/em>\u00e9, em \u00faltima inst\u00e2ncia, a principal conex\u00e3o entre a arquitetura de software e a escrita de c\u00f3digo.<\/strong><\/p>\n<h2>Postergando decis\u00f5es para o &#8220;\u00faltimo momento respons\u00e1vel&#8221;<\/h2>\n<p><strong>Toda decis\u00e3o implica em assumir riscos.<\/strong> Quanto antes uma decis\u00e3o \u00e9 tomada, maiores s\u00e3o os riscos associados a possibilidade dessa decis\u00e3o representar um erro causando preju\u00edzos.<\/p>\nO in\u00edcio dos projetos de desenvolvimento de software, onde tradicionalmente residem boa parte das &#8220;a\u00e7\u00f5es arquiteturais&#8221;, \u00e9, curiosamente, tamb\u00e9m, o momento onde se sabe menos sobre objetivos de neg\u00f3cio, restri\u00e7\u00f5es e atributos de qualidade.\n<hr \/>\n<p><img decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/imgs.xkcd.com\/comics\/the_general_problem.png\" alt=\"The General Problem\" \/><\/p>\n<hr \/>\nQuanto mais tarde, em um processo de desenvolvimento, uma decis\u00e3o \u00e9 tomada, maior \u00e9 quantidade de informa\u00e7\u00f5es dispon\u00edveis para fundamentar uma decis\u00e3o e, consequentemente, maiores s\u00e3o as chances de acerto e, proporcionalmente, menor \u00e9 o risco.\n<hr \/>\n<strong>As atividades de um arquiteto, em um contexto evolucion\u00e1rio, s\u00e3o o da busca constante da resolu\u00e7\u00e3o de incertezas. Ali\u00e1s, o grande inimigo \u00e9 a incerteza!\u00a0<\/strong>Isso n\u00e3o significa, entretanto que o arquiteto n\u00e3o deva ter, a todo momento, a &#8220;escolha-com-os-dados-de-agora&#8221;. Ou seja, documentos arquiteturais e discuss\u00f5es precisam revelar a &#8220;posi\u00e7\u00e3o atual&#8221; da arquitetura, indicando, por\u00e9m, onde est\u00e3o os pontos de maior incerteza.\n<hr \/>\n<p>No in\u00edcio dos projetos, a principal preocupa\u00e7\u00e3o dos arquitetos \u00e9 explicitar a estrat\u00e9gia &#8211; padr\u00f5es coerentes para tomada de decis\u00e3o &#8211; que deve ser observada nas escolhas. Se poss\u00edvel, essa &#8220;estrat\u00e9gia&#8221; precisa ser objetiva e observ\u00e1vel, expressa em<em> architectural fitness functions.\u00a0<\/em><strong>Arquitetura evolucion\u00e1ria n\u00e3o \u00e9 emergente, nem baseada em palpites.<\/strong><\/p>\n<h2>A evolu\u00e7\u00e3o demanda implementa\u00e7\u00e3o incremental das mudan\u00e7as<\/h2>\n<strong>O &#8220;represamento&#8221; das iniciativas para moderniza\u00e7\u00e3o tecnol\u00f3gica \u00e9 uma das maiores causas para a &#8220;morte&#8221; dos sistemas de software.<\/strong> Mesmo quando tecnologias n\u00e3o agregam &#8220;algo novo&#8221;, o afastamento da trajet\u00f3ria evolutiva das ferramentas, t\u00e9cnicas e pr\u00e1ticas por um tempo prolongado aumenta de maneira exponencial o custo e risco para a mudan\u00e7a, apesar dos custos de oportunidade.\n<hr \/>\n\u00c9 fundamental tentar &#8220;conectar&#8221; a atualiza\u00e7\u00e3o tecnol\u00f3gica com um benef\u00edcio tang\u00edvel, seja para o atingimento dos objetivos do neg\u00f3cio, respeito as restri\u00e7\u00f5es ou atributos de qualidade, implicando, invariavelmente em ganho econ\u00f4mico objetivo e mensur\u00e1vel. <strong>A falta da no\u00e7\u00e3o clara dos ganhos de uma mudan\u00e7a, em pelo menos uma dire\u00e7\u00e3o, \u00e9 sintoma da falta de maturidade para implantar tal mudan\u00e7a. Ali\u00e1s, racioc\u00ednio an\u00e1logo deve ser aplicado a d\u00edvidas t\u00e9cnicas: elas importam apenas quando cobram juros.<\/strong>\n<hr \/>\n<p style=\"padding-left: 40px;\"><em>Um sistema se torna legado quando nossa capacidade de pagar d\u00edvidas t\u00e9cnicas \u00e9 menor que a necessidade de contrair novas. (Fernando Paiva)<\/em><\/p>\n<p><strong>A boa arquitetura permite e facilita que atualiza\u00e7\u00f5es incrementais sejam realizadas.<\/strong> Um software onde o <em>front-end\u00a0<\/em>esteja &#8220;emaranhado&#8221; com a l\u00f3gica do neg\u00f3cio \u00e9, naturalmente, dif\u00edcil de atualizar tecnologicamente. Por outro lado, quando h\u00e1 &#8220;intelig\u00eancia demais&#8221; no front-end, a atualiza\u00e7\u00e3o \u00e9 mais dif\u00edcil.<\/p>\nA utiliza\u00e7\u00e3o de REST, por exemplo, pode facilitar a atualiza\u00e7\u00e3o tecnol\u00f3gica quando, al\u00e9m dos dados relacionados aos recursos, as a\u00e7\u00f5es poss\u00edveis sejam indicadas formando uma verdadeira m\u00e1quina de estados.\n<pre>HTTP\/1.1 200 OK\r\nContent-Type: application\/vnd.acme.account+json\r\nContent-Length: ...\r\n\r\n{\r\n    \"account\": {\r\n        \"account_number\": 12345,\r\n        \"balance\": {\r\n            \"currency\": \"usd\",\r\n            \"value\": 100.00\r\n        },\r\n        \"links\": {\r\n            \"deposit\": \"\/accounts\/12345\/deposit\",\r\n            \"withdraw\": \"\/accounts\/12345\/withdraw\",\r\n            \"transfer\": \"\/accounts\/12345\/transfer\",\r\n            \"close\": \"\/accounts\/12345\/close\"\r\n        }\r\n    }\r\n}\r\n<\/pre>\n<p>Decis\u00f5es de design assim, tiram do <em>front-end\u00a0<\/em>a responsabilidade de decidir quando mostrar, ou n\u00e3o, um bot\u00e3o ou <em>link<\/em>.<strong> Um dos grandes inimigos da implanta\u00e7\u00e3o de mudan\u00e7as \u00e9 o acoplamento e, por isso, ele deve ser evitado.<\/strong><\/p>\nFinalmente, para que mudan\u00e7as incrementais sejam implementadas da maneira certa, o conjunto mais leve de ferramentas e documenta\u00e7\u00e3o (<strong>protip<\/strong>: documenta\u00e7\u00e3o leve \u00e9 diferente de n\u00e3o-documenta\u00e7\u00e3o) deve ser implantado. <strong>Governan\u00e7a n\u00e3o \u00e9, nem pode ser, justificativa para &#8220;atrofiar a inova\u00e7\u00e3o&#8221;<\/strong>.\n<hr \/>\n<h2>A pr\u00e1tica da arquitetura evolutiva demanda m\u00e9tricas de qualidade interna<\/h2>\n<p><strong>C\u00f3digo limpo e f\u00e1cil de entender demanda menos esfor\u00e7o cognitivo e, por consequ\u00eancia, \u00e9 mais f\u00e1cil de mudar.\u00a0<\/strong><\/p>\n<p>Indicadores simples como complexidade aferente e eferente, quando bem analisados autorizam identificar e priorizar pontos de atua\u00e7\u00e3o e desafios arquiteturais para a mudan\u00e7a.<\/p>\n<p><img decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/hanselmanblogcontent.azureedge.net\/WindowsLiveWriter\/dfb0412cbf3d_CDC4\/ndepend01%5B8%5D.png\" width=\"524\" height=\"524\" \/><\/p>\nAn\u00e1lise da complexidade ciclom\u00e1tica, embora n\u00e3o seja precisa, costuma funcionar como um bom <em>proxy\u00a0<\/em>para identificar pontos do c\u00f3digo que ir\u00e3o consumir mais tempo para a mudan\u00e7a.\n<hr \/>\nFinalmente, a an\u00e1lise de frequ\u00eancia de mudan\u00e7as nos reposit\u00f3rios ajuda a determinar que c\u00f3digos s\u00e3o mais sujeitos a falha e onde mais documenta\u00e7\u00e3o faz diferen\u00e7a.\n<hr \/>\n<p><img decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/www.eximiaco.tech\/wp-content\/uploads\/sites\/2\/2020\/01\/number_of_commits_ravendb_server.png\" \/><\/p>\n<p>No gr\u00e1fico acima, podemos ver que h\u00e1 clara concentra\u00e7\u00e3o de\u00a0<em>commits\u00a0<\/em>em uma parcela muito pequena de arquivos no projeto do servidor do RavenDB, por exemplo. Um arquivo, apenas, recebeu 3% de todos os\u00a0<em>commits<\/em>. Mais de 50% dos\u00a0<em>commits\u00a0<\/em>envolveu menos de 10% de toda a base de c\u00f3digo. Parece evidente que as d\u00edvidas t\u00e9cnicas presentes nesses arquivos acabariam tendo impactos muito mais altos para a produtividade do time. Tamb\u00e9m parece l\u00f3gico que o c\u00f3digo desses arquivos fosse aquele com maior cobertura por testes automatizados.<\/p>\n<p>A implementa\u00e7\u00e3o de m\u00e9tricas e o acompanhamento vigilante previne que desvios grandes de qualidade aconten\u00e7am antes que algo possa ser feito para colocar as &#8220;coisas certas nos lugares certos&#8221;. Quando uma m\u00e9trica &#8220;sai do controle&#8221;, \u00e9 importante que a normalidade\u00a0 seja restabelecida no tempo certo.<\/p>\n\u00c9 importante entretanto n\u00e3o perder de vista da motiva\u00e7\u00e3o do interesse da arquitetura pelo c\u00f3digo: garantir o\u00a0<em>evolvability<\/em>!\n<hr \/>\n<h2>Arquiteturas evolutivas combatem as &#8220;origens&#8221; da complexidade<\/h2>\n<p><b>A complexidade tem quatro origens gen\u00e9ricas distintas que devem ser combatidas. S\u00e3o elas: dimensionalidade, interdepend\u00eancia, influ\u00eancia do ambiente e irreversibilidade.<\/b><\/p>\n<p>Quanto maior o n\u00famero de vari\u00e1veis envolvidas, maior ser\u00e1 a dimensionalidade. Por isso, por exemplo, qualquer software com mais\u00a0<i>features\u00a0<\/i>se torna mais complexo. A cada novo processo na organiza\u00e7\u00e3o, menor a simplicidade. Toda exce\u00e7\u00e3o suportada aumenta o custo.<\/p>\n<p><b>Opera\u00e7\u00f5es interdependentes demandam, por exemplo, sincroniza\u00e7\u00e3o.<\/b>\u00a0N\u00e3o raro, a indisponibilidade de um recurso impossibilita o uso de outro, aparentemente n\u00e3o relacionado. \u00c9 bastante comum que uma performance mais pobre de uma parte de um sistema deixe ele todo \u201clento\u201d.<\/p>\n<p>Sistemas mais \u201csens\u00edveis\u201d ao ambiente tamb\u00e9m s\u00e3o mais complexos. Afinal, demandam planejamento de conting\u00eancias e\u00a0<i>workarounds<\/i>.<\/p>\n<p>Finalmente, a irreversibilidade tamb\u00e9m demanda cuidados. A\u00e7\u00f5es ou eventos cujo ocorr\u00eancias resultem em consequ\u00eancias que n\u00e3o podem ser desfeitas implicam em custo maior de planejamento<del>, nem sempre eficiente. <\/del>Boa parte das estrat\u00e9gias modernas de desenvolvimento conta com o pressuposto de um \u201crollback\u201d r\u00e1pido. Este \u00e9 o fundamento de iniciativas operacionais como DevOps.<\/p>\n<p>Naturalmente, sistemas tendem para o incremento da dimensionalidade e da interdepend\u00eancia. Al\u00e9m disso, em ambientes cada vez mais abrangentes, \u00e9 dif\u00edcil controlar o impacto do ambiente, marcando, de forma irrevers\u00edvel impactos e preju\u00edzos. \u00a0<b>Se o empenho de um time for orientado a apenas manter os n\u00edveis atuais de complexidade, essa ir\u00e1 aumentar.<\/b><\/p>\n<h2>Sistemas que seguem a lei de Postel evoluem mais f\u00e1cil<\/h2>\n<p id=\"a121\" class=\"gr gs dt gt b gu gv gw gx gy gz ha hb hc hd he hf hg hh hi hj hk hl hm hn ho dl eq\" data-selectable-paragraph=\"\">A\u00a0<strong class=\"gt io\">Lei de Postel<\/strong>\u00a0\u2014 ou Lei da Robustez \u2014 \u00e9 um princ\u00edpio originalmente descrito como um guia para a\u00a0<strong class=\"gt io\">transfer\u00eancia de dados<\/strong> entre softwares. Contudo, ela \u00e9 bastante compat\u00edvel com arquitetura.<\/p>\n<p data-selectable-paragraph=\"\">A lei preconiza que sistemas sejam 1) conservadores no que enviam e ; 2) liberais no que recebem;<\/p>\n<p data-selectable-paragraph=\"\"><img decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/imgs.xkcd.com\/comics\/standards.png\" alt=\"Standards\" \/><\/p>\n<h2>A evolu\u00e7\u00e3o \u00e9 segura quando <em>&#8220;fitness functions&#8221;\u00a0<\/em>s\u00e3o determinadas<\/h2>\n<p>&#8220;<em>Architectural Fitness Functions<\/em>&#8221; \u00e9 um conceito inspirado nas <em>fitness functions<\/em> utilizadas com algoritmos gen\u00e9ticos.<\/p>\n<p style=\"padding-left: 40px;\"><em>Uma fun\u00e7\u00e3o de adequa\u00e7\u00e3o (fitness function) \u00e9 um tipo particular de fun\u00e7\u00e3o objetivo que \u00e9 usada para resumir, como uma \u00fanica figura de m\u00e9rito, o qu\u00e3o perto uma determinada solu\u00e7\u00e3o de design est\u00e1 de atingir os objetivos definidos. As fun\u00e7\u00f5es de adequa\u00e7\u00e3o s\u00e3o usadas em programa\u00e7\u00e3o gen\u00e9tica e algoritmos gen\u00e9ticos para orientar as simula\u00e7\u00f5es em dire\u00e7\u00e3o a solu\u00e7\u00f5es de arranjo ideais. (Wikipedia)\u00a0<\/em><\/p>\n<p><strong>Uma &#8220;<em>architectural fitness function<\/em>&#8221; deve proteger as diversas propriedades de um sistema de software na medida em que modifica\u00e7\u00f5es, preferencialmente incrementais, s\u00e3o realizadas.<\/strong> De maneira objetiva, uma solu\u00e7\u00e3o implementada deve ser submetida sob a perspectiva de diversas <em>fitness functions\u00a0<\/em>para garantir que todas as adapta\u00e7\u00f5es realizadas n\u00e3o impactam no atingimento dos objetivos de neg\u00f3cio, restri\u00e7\u00f5es ou atributos de qualidade que suportam. Toda vez que uma <em>fitness function\u00a0<\/em>indicar afastamento do objetivo, sabe-se que h\u00e1 um problema a analisar ou adapta\u00e7\u00e3o a rever na arquitetura.<\/p>\nUm exemplo de <em>fitness function\u00a0<\/em>s\u00e3o as medidas de <em>response time\u00a0<\/em>de um servi\u00e7o. Afinal, trata-se de express\u00e3o objetiva da performance (um dos diversos atributos de qualidade poss\u00edvel). Dependendo da &#8220;gravidade&#8221; a medi\u00e7\u00e3o de <em>fitness functions\u00a0<\/em>poder\u00e1 ser realizada nos ambientes de desenvolvimento, homologa\u00e7\u00e3o e produ\u00e7\u00e3o.\n<hr \/>\nA manutenabilidade de um c\u00f3digo-fonte, outro atributo de qualidade, pode ser avaliada utilizando uma\u00a0<em>fitness function<\/em> que &#8220;pondera&#8221; sobre diversas outras, como cobertura por testes, \u00edndices de acoplamento e outras m\u00e9tricas fornecidas por ferramentas de an\u00e1lise est\u00e1tica.\n<hr \/>\nA qualidade das integra\u00e7\u00f5es de um sistema pode ser avaliada com uma\u00a0<em>fitness function\u00a0<\/em>que avalie a quantidade de implementa\u00e7\u00f5es realizadas\u00a0<em>contract models\u00a0<\/em>(uma medida est\u00e1tica), ou ainda, o respeito aos contratos estabelecidos (uma medida din\u00e2mica).\n<hr \/>\nAdequa\u00e7\u00e3o jur\u00eddica das licen\u00e7as dos softwares consumidos por um sistema de software pode ser determinada por uma\u00a0<em>fitness function\u00a0<\/em>que verifique, em cada atualiza\u00e7\u00e3o, se os contratos foram alterados e &#8220;acionando advogados&#8221; quando necess\u00e1rio.\n<hr \/>\nCada\u00a0<em>architectural fitness function\u00a0<\/em>consiste em uma decis\u00e3o arquitetural importante, que precisa ser devidamente registrada em uma ADR.\n<hr \/>\n<h2>Toda grande jornada tem desvios, atalhos e &#8230; aprendizado<\/h2>\n<p><strong>Os sistemas mais interessantes (e \u00fateis) costumam come\u00e7ar com uma excelente dire\u00e7\u00e3o, mas, raramente escopo claramente delimitado.<\/strong> Se h\u00e1 uma certeza \u00e9 de que requisitos mudam, condi\u00e7\u00f5es t\u00e9cnicas tamb\u00e9m.<\/p>\n<p>Arquiteturas de software de qualidade s\u00e3o, acima de tudo, aquelas que permitem que mudan\u00e7as de rumo sejam feitas com menos trauma poss\u00edvel. Quanto mais &#8220;f\u00e1cil de mudar&#8221;, maior o espa\u00e7o entre eventuais descontinuidades.<\/p>\n<h2>\/\/ TODO<\/h2>\n<p>Antes de avan\u00e7ar para o pr\u00f3ximo cap\u00edtulo, recomendo as seguintes reflexo\u00f5es:<\/p>\n<ul>\n<li>\u00c9 poss\u00edvel expressar objetivos, atributos de qualidade e restri\u00e7\u00f5es do sistema em que est\u00e1 trabalhando de forma objetiva?<\/li>\n<li>As m\u00e9tricas de qualidade interna est\u00e3o orientadas a facilitar a manutenabilidade?<\/li>\n<li>Quais partes do seu sistema demandam mais testes?<\/li>\n<li>Qual o n\u00edvel de acoplamento atual do frontend com l\u00f3gicas de neg\u00f3cio?<\/li>\n<\/ul>\n","protected":false},"featured_media":1448,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[],"sessoes":[57],"apendices":[],"capitulos":[24],"class_list":["post-1390","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","sessoes-secao-1","capitulos-capitulo-1-5"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.6 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Software relevante evolui... e a arquitetura precisa suportar isso! \/ Cap\u00edtulo 3 v1.00 - 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\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Software relevante evolui... e a arquitetura precisa suportar isso! \/ Cap\u00edtulo 3 v1.00 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Software relevante evolui! Seja para atender novas demandas do neg\u00f3cio, seja para incorporar novidades tecnol\u00f3gicas, adapta\u00e7\u00f5es s\u00e3o sempre necess\u00e1rias. Enquanto isso, \u00e9 fato que modificar software fica, geralmente, mais dif\u00edcil com o tempo. Apesar de nossos melhores esfor\u00e7os, o software se torna mais dif\u00edcil de alterar com o tempo. Por uma variedade de raz\u00f5es, as [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/\" \/>\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-11T21:09:40+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/johannes-plenio-aWDgqexSxA0-unsplash.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"576\" \/>\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=\"16 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\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/\",\"name\":\"Software relevante evolui... e a arquitetura precisa suportar isso! \/ Cap\u00edtulo 3 v1.00 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/johannes-plenio-aWDgqexSxA0-unsplash.jpg\",\"datePublished\":\"2021-04-23T18:14:55+00:00\",\"dateModified\":\"2024-01-11T21:09:40+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/johannes-plenio-aWDgqexSxA0-unsplash.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/johannes-plenio-aWDgqexSxA0-unsplash.jpg\",\"width\":1024,\"height\":576},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#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\":\"Software relevante evolui&#8230; e a arquitetura precisa suportar isso! \/ Cap\u00edtulo 3 v1.00\"}]},{\"@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":"Software relevante evolui... e a arquitetura precisa suportar isso! \/ Cap\u00edtulo 3 v1.00 - 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\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/","og_locale":"pt_BR","og_type":"article","og_title":"Software relevante evolui... e a arquitetura precisa suportar isso! \/ Cap\u00edtulo 3 v1.00 - Manual do Arquiteto de Software","og_description":"Software relevante evolui! Seja para atender novas demandas do neg\u00f3cio, seja para incorporar novidades tecnol\u00f3gicas, adapta\u00e7\u00f5es s\u00e3o sempre necess\u00e1rias. Enquanto isso, \u00e9 fato que modificar software fica, geralmente, mais dif\u00edcil com o tempo. Apesar de nossos melhores esfor\u00e7os, o software se torna mais dif\u00edcil de alterar com o tempo. Por uma variedade de raz\u00f5es, as [&hellip;]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-11T21:09:40+00:00","og_image":[{"width":1024,"height":576,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/johannes-plenio-aWDgqexSxA0-unsplash.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"16 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/","name":"Software relevante evolui... e a arquitetura precisa suportar isso! \/ Cap\u00edtulo 3 v1.00 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/johannes-plenio-aWDgqexSxA0-unsplash.jpg","datePublished":"2021-04-23T18:14:55+00:00","dateModified":"2024-01-11T21:09:40+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/johannes-plenio-aWDgqexSxA0-unsplash.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/04\/johannes-plenio-aWDgqexSxA0-unsplash.jpg","width":1024,"height":576},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/software-relevante-evolui-e-a-arquitetura-precisa-suportar-isso-capitulo-3-v1-00\/#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":"Software relevante evolui&#8230; e a arquitetura precisa suportar isso! \/ Cap\u00edtulo 3 v1.00"}]},{"@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\/1390","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=1390"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/1448"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=1390"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=1390"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=1390"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=1390"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=1390"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}