{"id":1560,"date":"2021-05-06T09:10:49","date_gmt":"2021-05-06T12:10:49","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=1560"},"modified":"2024-01-11T17:50:56","modified_gmt":"2024-01-11T20:50:56","slug":"nunca-ignore-o-acoplamento-capitulo-4-v1-03","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/","title":{"rendered":"Nunca ignore o acoplamento! \/ Cap\u00edtulo 4 v1.03"},"content":{"rendered":"O alto acoplamento \u00e9, provavelmente, a principal caracter\u00edstica de sistemas dif\u00edceis de evoluir e, at\u00e9 mesmo, de manter.<\/strong> Por esse motivo, as decis\u00f5es de design<\/em>, n\u00e3o apenas as relacionadas \u00e0 arquitetura, devem mitigar as chances de que ele aconte\u00e7a.\n
\nUma das muitas causas para o surgimento do acoplamento, sob a perspectiva arquitetural, s\u00e3o o choque de duas for\u00e7as. De um lado, h\u00e1 um incentivo constante para o desenvolvimento de integra\u00e7\u00f5es, cada vez mais amplas, em tempos cada vez menores. De outro, h\u00e1 o desejo de garantir governan\u00e7a e manter as efici\u00eancias dos times que ficam, evidentemente, prejudicadas em fun\u00e7\u00e3o do aumento da complexidade e da dificuldade para a “garantia da qualidade”, por causa das integra\u00e7\u00f5es, levando a pol\u00edticas de controle, muitas vezes, insustent\u00e1veis. Esse “aperta-solta”\u00a0 colabora para a eros\u00e3o arquitetural.<\/strong>\n
\n

\"Sandboxing<\/p>\nO combate ao acoplamento \u00e9 uma das principais motiva\u00e7\u00f5es para padr\u00f5es de\u00a0design<\/em> e pr\u00e1ticas de engenharia populares – como invers\u00e3o de controle, decomposi\u00e7\u00e3o em microsservi\u00e7os, comunica\u00e7\u00e3o ass\u00edncrona, CQRS, <\/span>event-driven<\/span><\/i>, distribui\u00e7\u00e3o em camadas, <\/span>testes e muito mais. Ali\u00e1s, boa parte dos “problemas” percebidos na implementa\u00e7\u00e3o desses padr\u00f5es e pr\u00e1ticas decorre da “ignor\u00e2ncia” desse prop\u00f3sito.<\/strong><\/span>\n

\n

Acoplamento aferente e eferente<\/h2>\n

O acoplamento “nasce” de diversas formas, mas assume apenas duas naturezas gen\u00e9ricas distintas: aferente e eferente.<\/p>\n

O acoplamento aferente de um artefato – seja ele um componente, classe, fun\u00e7\u00e3o, etc – surge quando este \u00e9 referenciado por outro.<\/strong> Quando, por exemplo, o c\u00f3digo de uma classe “A” faz refer\u00eancia ao c\u00f3digo de uma classe “B”, diz-se que “B” tem um incremento em seu acoplamento aferente. Por outro lado, o acoplamento eferente de um artefato surge quando este demanda (ou depende) de outro.<\/strong><\/p>\n

\"\"<\/p>\n

Artefatos com acoplamento eferente mais alto “quebram” com mais frequ\u00eancia<\/strong>, pois, al\u00e9m de sua qualidade interna, s\u00e3o fortemente impactados pela qualidade interna de suas depend\u00eancias.<\/p>\n

\"\"<\/p>\n

Artefatos com acoplamento aferente alto s\u00e3o potenciais “pontos de falha” graves<\/strong>. Afinal de contas, problemas em sua qualidade interna afetam todos os que dele dependem.<\/p>\n

\"\"<\/p>\n

Um indicador derivado das m\u00e9tricas de acoplamentos aferente e eferente \u00e9 a instabilidade. Trata-se da propor\u00e7\u00e3o, em um determinado artefato, de acoplamento eferente em rela\u00e7\u00e3o ao acoplamento total.<\/p>\n

\"\"<\/p>\n

Quanto maior a instabilidade ponderada de um conjunto de artefatos, em um determinado m\u00f3dulo, maiores s\u00e3o as chances de “quebra”.<\/p>\n

O “problema” das depend\u00eancias externas<\/h2>\nEm todo sistema relevante, h\u00e1 sempre um bocado de depend\u00eancias para componentes externos. As depend\u00eancias estabelecidas em componentes com maior acoplamento aferente t\u00eam, pelo menos em teoria, maior criticidade.<\/strong> Logo, demandam mais cuidados e gest\u00e3o para mudan\u00e7a (atualiza\u00e7\u00e3o). Entretanto, esse “aumento do cuidado”, se implementado de maneira ing\u00eanua, tende ao aumento perigoso de “burocracia ruim”.\n
\n

<\/p>\nQuanto maior complexidade aferente uma depend\u00eancia externa possuir, maior, tamb\u00e9m \u00e9 a criticidade para sua manuten\u00e7\u00e3o e, tamb\u00e9m, maior a tenta\u00e7\u00e3o para aumentar o “controle” sobre seu desenvolvimento, inclinando times, muitas vezes, a “reinventar a roda” ou, ainda mais impactante, trazer fornecedores para “dentro de casa”<\/strong>. Em grandes organiza\u00e7\u00f5es, isso consiste em dificuldade para organiza\u00e7\u00e3o de times e, em casos extremos, tornam inquestion\u00e1veis a relev\u00e2ncia da gest\u00e3o de c\u00f3digo envolvendo open sourcing\u00a0<\/em>ou\u00a0inner sourcing<\/em>.\n

\n

Em grandes organiza\u00e7\u00f5es h\u00e1 um “misto de emo\u00e7\u00f5es” com rela\u00e7\u00e3o a “abertura” das depend\u00eancias externas. H\u00e1 quem considere arriscado em demasia “confiar” em padr\u00f5es e tecnologias “fechadas”. Da\u00ed, aderem a pol\u00edtica de somente utilizar tecnologias e padr\u00f5es “abertos”. No outro extremo, h\u00e1 quem suspeite, muitas vezes por ignor\u00e2ncia, da gest\u00e3o do\u00a0roadmap\u00a0<\/em>e das motiva\u00e7\u00f5es das iniciativas mais abertas, optando por “marcas” no lugar de evid\u00eancias (cover my ass strategy<\/em>).<\/em><\/p>\n

<\/p>\n

O “problema” do banco de dados monol\u00edtico<\/h2>\n

O banco de dados \u00e9 componente importante na maioria das aplica\u00e7\u00f5es.<\/p>\n

Tradicionalmente, grandes aplica\u00e7\u00f5es concentram as informa\u00e7\u00f5es de todos os seus m\u00f3dulos em um mesmo banco de dados. Uma das justificativas \u00e9 que isso simplifica a integra\u00e7\u00e3o entre estes m\u00f3dulos. O “problema”, entretanto, \u00e9 que junto com a potencial simplicidade de integra\u00e7\u00e3o h\u00e1 o crescimento do acoplamento aferente.\u00a0<\/strong>Afinal, falhas no banco de dados s\u00e3o cada vez mais impactantes na medida em que mais “m\u00f3dulos” compartilham dele.<\/p>\n

\"\"<\/p>\n

A eventualidade de decomposi\u00e7\u00e3o de um sistema em servi\u00e7os, ou microsservi\u00e7os, preservando o banco de dados monol\u00edtico potencializa o problema.<\/p>\nH\u00e1, no mercado, solu\u00e7\u00f5es de integra\u00e7\u00e3o que envelopam o banco de dados, expondo informa\u00e7\u00f5es a partir de um “servi\u00e7o de dados”. Importante, entretanto, observar que, tais solu\u00e7\u00f5es, se implementadas de maneira ing\u00eanua, apenas transferem o acoplamento aferente do banco para o “servi\u00e7o”, aumentando as chances de “vendor locking<\/em>“. \n

\n

CQRS: Segrega\u00e7\u00e3o combatendo o acoplamento<\/h2>\n

Muitas aplica\u00e7\u00f5es LOB\u00a0<\/em>(Line-Of-Business<\/em>) s\u00e3o projetadas para agrupar componentes conforme sua fun\u00e7\u00e3o prim\u00e1ria. N\u00e3o raro, a estrat\u00e9gia adotada classifica componentes em apresenta\u00e7\u00e3o,\u00a0<\/em>neg\u00f3cio (juntando aplica\u00e7\u00e3o e dom\u00ednio) e\u00a0infraestrutura.<\/p>\n

\"\"<\/p>\nNessa vis\u00e3o os componentes de apresenta\u00e7\u00e3o, que “interagem” com o usu\u00e1rio, integram ao sistema recebendo dados, atrav\u00e9s de viewmodels, <\/em>e enviando dados, com inputmodels. <\/em>Ali\u00e1s, essa distin\u00e7\u00e3o forte entre inputmodels <\/em>e viewmodels, <\/em>embora aumente a complexidade (pelo incremento da dimensionalidade), \u00e9, muitas vezes, prefer\u00edvel a uma \u00fanica DTO por aliviar o acoplamento aferente (de um objeto \u00fanico), simplificando mudan\u00e7as e, potencialmente, aumentando o evolvability<\/em>.\n

\n

\"\"<\/p>\n

Cabe a camada de aplica\u00e7\u00e3o “traduzir” os\u00a0inputmodels\u00a0<\/em>em comandos que, na pr\u00e1tica, s\u00e3o solicita\u00e7\u00f5es para modifica\u00e7\u00f5es de estado (mudan\u00e7a de dados perceb\u00edveis no longo prazo). Ali\u00e1s, essa “especializa\u00e7\u00e3o”, permite tamb\u00e9m a distin\u00e7\u00e3o, quando necess\u00e1rio, de m\u00e9tricas de performance importantes para opera\u00e7\u00f5es de longa dura\u00e7\u00e3o, habilitando \u00eanfase de response time\u00a0<\/em>para a aplica\u00e7\u00e3o e de\u00a0throughput<\/em> para o dom\u00ednio, atrav\u00e9s da inclus\u00e3o de um componente para mensageria.<\/p>\n

\r\n

M\u00e9tricas de performance e componentiza\u00e7\u00e3o<\/p>\r\nCertifique-se de adotar m\u00e9tricas apropriadas de performance para cada natureza de opera\u00e7\u00e3o.<\/p>\n

\n

Se uma opera\u00e7\u00e3o demandar, ao mesmo tempo, controle tanto de response time\u00a0<\/em>quanto\u00a0throughput<\/em>, h\u00e1 claros ind\u00edcios de revis\u00e3o arquitetural.<\/strong><\/div>\n

\"\"<\/p>\n

Tal medida, ali\u00e1s, reduz o acoplamento aferente do dom\u00ednio, tranferindo-o para o mecanismo de mensageria que, geralmente, tem menos demanda para mudan\u00e7as e \u00e9 ser mais “est\u00e1vel” (protocolo AMQP n\u00e3o recebe altera\u00e7\u00f5es desde 2012<\/a>).<\/p>\nO “pulo do gato” est\u00e1 em identificar que o “dom\u00ednio” pode ser pesado demais para a composi\u00e7\u00e3o de viewmodels\u00a0<\/em>e pode acabar sendo “penalizado” pelo crescimento do acoplamento aferente decorrente da “instabilidade” das consultas, comum em aplica\u00e7\u00f5es LOB<\/em>. Eventualmente, n\u00e3o seria m\u00e1 ideia segregar modelos para aliviar tal acoplamento.\n

\n

 <\/p>\n

\"\"<\/p>\n

Esta segrega\u00e7\u00e3o do neg\u00f3cio em modelos distintos para comandos e consultas (Command Query Responsibility Segregation – CQRS<\/em>) literalmente “divide” o acoplamento aferente da camada de neg\u00f3cios em duas partes, aumentando o custo potencial de desenvolvimento, por\u00e9m, geralmente, reduzindo o custo de manuten\u00e7\u00e3o, por\u00e9m, aumentando o acoplamento aferente para o banco de dados.<\/p>\n

\"\"<\/p>\n

Em cen\u00e1rios extremos, o pr\u00f3prio banco de dados pode ser “segregado” para fun\u00e7\u00f5es de grava\u00e7\u00e3o e consulta (algo bem comum, se pensar na utiliza\u00e7\u00e3o de mecanismos de\u00a0caching<\/em>) com vistas a reduzir o acoplamento aferente desse componente, com impacto positivo na escala, mas negativo no custo.<\/p>\n

\r\n

Caching, mensageria e a escalabilidade<\/p>\r\nMensageria e caching\u00a0<\/em>s\u00e3o chaves para sistemas escal\u00e1veis. Por\u00e9m, aumentam a complexidade da solu\u00e7\u00e3o pelo incremento da dimensionalidade.<\/div>\n

Combatendo acoplamento com abstra\u00e7\u00f5es<\/h2>\n

Um dos principais recursos para a redu\u00e7\u00e3o o acoplamento aferente, pelo menos do ponto de vista est\u00e1tico, \u00e9 a introdu\u00e7\u00e3o de abstra\u00e7\u00f5es<\/strong>. Ou seja, a substitui\u00e7\u00e3o das depend\u00eancias de implementa\u00e7\u00f5es concretas por abstratas, como interfaces e\/ou contratos.<\/p>\nA introdu\u00e7\u00e3o de abstra\u00e7\u00f5es\u00a0 – como delegates<\/em>, high order functions<\/em>, interfaces, classes abstratas e contratos de servi\u00e7o – transfere o acoplamento das implementa\u00e7\u00f5es concretas para estas abstra\u00e7\u00f5es. Geralmente, isso causa al\u00edvio de complexidade e viabiliza o isolamento mais efetivo das unidades, facilitando, entre outras coisas a escrita de testes automatizados. Entretanto, quando abstra\u00e7\u00f5es s\u00e3o criadas em demasia, cresce a dificuldade dos desenvolvedores para entender como os componentes se conectam no contexto din\u00e2mico (durante a execu\u00e7\u00e3o), aumentando o volume de carga cognitiva necess\u00e1ria para o trabalho e, consequentemente, custos de desenvolvimento.<\/strong>\n

\n

\"\"<\/p>\n

As abstra\u00e7\u00f5es tendem a se tornar “dif\u00edceis de mudar” na medida em que o software vai sofrendo adapta\u00e7\u00f5es, com a cria\u00e7\u00e3o de mais implementa\u00e7\u00f5es concretas.<\/p>\n

\"\"<\/p>\n

Entretanto, bem mais comum (e bem menos controlada) \u00e9 a prolifera\u00e7\u00e3o de artefatos “consumidores”, operando atrav\u00e9s de invers\u00e3o de controle ou mecanismos de descoberta.<\/p>\n

\"\"<\/p>\n

Essa “prolifera\u00e7\u00e3o descontrolada”, ali\u00e1s, \u00e9 a justificativa para que aprimoramentos sejam explicitados em abstra\u00e7\u00f5es novas, de maneira a n\u00e3o quebrar contratos mais antigos e potencialmente n\u00e3o evidentes.<\/p>\n

\"\"<\/p>\n

O volume de abstra\u00e7\u00e3o tamb\u00e9m \u00e9 uma m\u00e9trica arquitetural interessante. De maneira simples, trata-se da propor\u00e7\u00e3o, em um determinado escopo, da quantidade de abstra\u00e7\u00f5es com rela\u00e7\u00e3o a quantidade de implementa\u00e7\u00f5es concretas.<\/p>\n

\"\"<\/p>\n

 <\/p>\n

O “lado ruim” da testabilidade<\/h2>\nO “efeito colateral”, geralmente positivo, da testabilidade de um sistema \u00e9 a redu\u00e7\u00e3o do acoplamento aferente est\u00e1tico, pela introdu\u00e7\u00e3o de abstra\u00e7\u00f5es, necess\u00e1rias para a escrita de testes de unidade.<\/strong> O problema \u00e9 que a introdu\u00e7\u00e3o de abstra\u00e7\u00f5es implica em aumento da complexidade din\u00e2mica que precisar\u00e1 ser compensada pela prote\u00e7\u00e3o contra regress\u00f5es que os testes, em teoria, v\u00e3o apoiar.\u00a0\n
\nArtefatos inst\u00e1veis, ainda em desenvolvimento, podem demandar atualiza\u00e7\u00f5es nas abstra\u00e7\u00f5es que os representam que, como sabemos, tem complexidade aferente sempre maior. Por isso, com frequ\u00eancia \u00e9 justific\u00e1vel postergar a inclus\u00e3o de abstra\u00e7\u00f5es, mesmo sob pena de reduzir a testabilidade.\n
\n

O “lado ruim” de\u00a0IRepository<\/em><\/h2>\n

Uma pr\u00e1tica comum em implementa\u00e7\u00f5es baseadas em Domain-driven Design<\/em> \u00e9 a separa\u00e7\u00e3o entre contrato (interface p\u00fablica) para reposit\u00f3rios, geralmente colocados no mesmo pacote destinado aos objetos que formam o modelo do dom\u00ednio, das implementa\u00e7\u00f5es concretas. A justificativa mais comum \u00e9 dar “liberdade” para a eventualidade de trocar a tecnologia de persist\u00eancia. Outra justificativa, \u00e9 facilitar a escrita de testes automatizados.<\/p>\nNa pr\u00e1tica, o que se tem verificado \u00e9 que raramente sistemas precisam, realmente, suportar mais do que uma tecnologia de persist\u00eancia. No fim, o que se constata s\u00e3o replica\u00e7\u00f5es rasas das interfaces p\u00fablicas fornecidas pelas bibliotecas que fazem “conex\u00e3o” com os bancos ou, pior, nivelamento por baixo com base nas caracter\u00edsticas mais gen\u00e9ricas dentre duas alternativas poss\u00edveis.<\/strong> (Por exemplo, RavenDB e MongoDB s\u00e3o dois bancos de dados NoSQL de documentos. RavenDB suporta transa\u00e7\u00f5es. Mongo, n\u00e3o! Uma interface “abstrata” teria que descartar essa\u00a0feature\u00a0<\/em>do RavenDB).\n

\nQuanto a “testabilidade”, boa parte das bases de c\u00f3digo concentra seus usos de reposit\u00f3rios em servi\u00e7os de aplica\u00e7\u00e3o que, por sua vez, tem baixo acoplamento afaerente e elevado acoplamento eferente. Ou seja, menos demandantes de testes de unidade. Dessa forma, as famigeradas “interfaces” acabam servindo apenas para viabilizar testes que agregam pouco (ou nenhum) valor.\n
\n

O “lado ruim” das APIs p\u00fablicas<\/h2>\n

APIs p\u00fablicas tem acoplamento aferente din\u00e2mico dif\u00edcil de medir<\/strong>. Entretanto, como se sabe, quanto mais bem sucedidas, geralmente maior ser\u00e1 tal acoplamento e, consequentemente, maiores ser\u00e3o as dificuldades para evoluir. Essa \u00e9 a raz\u00e3o principal para o versionamento eficiente dos contratos p\u00fablicos, com pol\u00edticas claras para descontinuidades.<\/p>\nUm “ant\u00eddoto” para o problema das APIs p\u00fablicas com acoplamento aferente muito grande \u00e9 a segmenta\u00e7\u00e3o das APIs em externas e internas.<\/strong> As APIs externas ser\u00e3o aquelas que ir\u00e3o atender publicamente demandas bem delimitadas, e internas, ir\u00e3o apenas expor funcionalidades e capabilities. <\/em>Tal solu\u00e7\u00e3o, entretanto, tem como custo o aumento da dimensionalidade e, em consequ\u00eancia da complexidade. Em sistemas maiores, quase sempre \u00e9 necess\u00e1rio desenvolver algum mecanismo de media\u00e7\u00e3o.<\/strong>\n

\n

O “lado ruim” das arquiteturas event-driven<\/em><\/h2>\n

Outro “ant\u00eddoto” comum para a complexidade aferente \u00e9 ado\u00e7\u00e3o de comunica\u00e7\u00e3o atrav\u00e9s de eventos. Ali\u00e1s, essa \u00e9 uma “bomba” contra o acoplamento que, como tal, acaba tendo efeitos colaterais nem sempre desej\u00e1veis.<\/strong><\/p>\n

Sistemas baseados em eventos demandam o planejamento de coreografias, regulando o comportamento din\u00e2mico, tremendamente dif\u00edceis de entender sem o suporte de documenta\u00e7\u00e3o eficiente.<\/p>\n

\"Choreography\"<\/p>\n

A alternativa \u00e9 a introdu\u00e7\u00e3o de componentes especificamente dedicados a orquestra\u00e7\u00e3o, por\u00e9m, estes, acabam comprometidos por terem alto acoplamento aferente.<\/p>\n

\"Orchestration\"<\/p>\n

 <\/p>\n

Determinando o volume ideal de abstra\u00e7\u00f5es<\/h2>\nComo j\u00e1 foi dito, transferir acoplamento aferente de algumas implementa\u00e7\u00f5es concretas para abstra\u00e7\u00f5es pode simplificar a manutenabilidade dos sistemas, aprimorando o evolvability<\/em>. Entretanto, abstra\u00e7\u00f5es em demasia, ou para artefatos errados, tornam sistemas mais dif\u00edceis de entender e caros para manter.\n
\n

O volume ideal de abstra\u00e7\u00f5es tem rela\u00e7\u00e3o direta com a instabilidade observada<\/strong>. Quando maior a instabilidade de um artefato, menor a necessidade de uma abstra\u00e7\u00e3o que alivie seu acoplamento aferente. Por outro lado, artefatos com baixa instabilidade “gritam” por abstra\u00e7\u00f5es.<\/p>\n

\"\"<\/p>\n

No gr\u00e1fico indicado acima, artefatos que se posicionem no canto superior-direito se encaixam na\u00a0zone of uselessness<\/em>, ou seja, c\u00f3digo t\u00e3o abstrato que se converte em algo dif\u00edcil de manter. No outro extremo, artefatos que se posicionem no canto inferior esquerdo est\u00e3o na\u00a0zone of pain,\u00a0<\/em>ou seja, acoplamento aferente extremamente elevado sem o “al\u00edvio” de abstra\u00e7\u00f5es que habilitem testabilidade e novas implementa\u00e7\u00f5es.<\/p>\n

A medida de desequil\u00edbrio entre a instabilidade e o volume de abstra\u00e7\u00f5es de um software pode ser determinada pela dist\u00e2ncia da condi\u00e7\u00e3o atual e a propor\u00e7\u00e3o adequada.<\/p>\n

\"\"<\/p>\n

Modularidade<\/h2>\n

Um m\u00f3dulo \u00e9, por defini\u00e7\u00e3o, um agrupamento de unidades independentes que pode ser utilizado para a composi\u00e7\u00e3o de estruturas mais complexas.<\/strong><\/p>\nM\u00f3dulos estabelecem limites para “acoplamento mais seguro”, afinal, est\u00e3o dentro de um mesmo “espa\u00e7o de manuten\u00e7\u00e3o”<\/strong>. Dessa forma, o acoplamento de artefatos dentro de um mesmo m\u00f3dulo \u00e9 sempre prefer\u00edvel aos externos.\n

\n

No dia-a-dia, os desenvolvedores t\u00eam diferentes recursos para expressar modularidade. Come\u00e7ando pelo n\u00edvel b\u00e1sico, em m\u00e9todos e fun\u00e7\u00f5es, at\u00e9 n\u00edveis mais altos, como classes, pacotes ou namespaces<\/em> e assemblies<\/span><\/em> – todas essas op\u00e7\u00f5es com diferentes pr\u00e1ticas e pol\u00edticas para regras de escopo e visibilidade. Quanto mais fr\u00e1geis as “fronteiras” de cada m\u00f3dulo, maiores s\u00e3o as dificuldades para o evolvability<\/em>.<\/p>\n

\nM\u00f3dulos muito grandes s\u00e3o, por associa\u00e7\u00e3o, mais complexos<\/strong>, logo, demandantes de maior esfor\u00e7o cognitivo para o entendimento. Por conta disso, precisam ser mantidos por times com mais integrantes, com custo mais alto de gest\u00e3o. M\u00f3dulos muito pequenos geralmente s\u00e3o menos coesos e com mais demanda para acoplamento eferente, por isso, muito mais inst\u00e1veis.<\/strong>\n
\n

O tamanho certo para os m\u00f3dulos de um sistema de software extrapolam caracter\u00edsticas t\u00e9cnicas e tem rela\u00e7\u00e3o direta com o n\u00edvel de maturidade das organiza\u00e7\u00f5es que os mant\u00e9m.<\/p>\n

A coes\u00e3o do m\u00f3dulo \u00e9 determinada pela clara liga\u00e7\u00e3o entre os artefatos que o constituem. Quanto menor a coes\u00e3o, maiores as chances de eros\u00e3o.<\/p>\n

A modulariza\u00e7\u00e3o \u00e9 um recurso fundamental para a gest\u00e3o do acoplamento.<\/strong><\/p>\n

O “lado ruim” de microsservi\u00e7os<\/h2>\n

A fragmenta\u00e7\u00e3o de microsservi\u00e7os \u00e9, em ess\u00eancia, uma estrat\u00e9gia para defini\u00e7\u00e3o da modularidade de um sistema de software, mas n\u00e3o \u00e9 a \u00fanica!<\/strong><\/p>\n

Sob a perspectiva da gest\u00e3o do acoplamento, microsservi\u00e7os agrupam uma s\u00e9rie de artefatos – incluindo c\u00f3digo, banco de dados, mecanismos de replica\u00e7\u00e3o, etc – localizando o acoplamento entre eles, tentando preservar a coes\u00e3o. Al\u00e9m disso, t\u00eam suas funcionalidades expostas de maneira controlada e bem versionada.<\/p>\nO “problema” \u00e9 que atingir o n\u00edvel necess\u00e1rio de coes\u00e3o para um microsservi\u00e7o \u00e9 dif\u00edcil.<\/strong> N\u00e3o raro, implementa\u00e7\u00f5es ing\u00eanuas desta estrat\u00e9gia de modularidade gera artefatos (microsservi\u00e7os, no caso), com \u00edndices gigantescos de acoplamento eferente, tornando-os inst\u00e1veis. Al\u00e9m disso, tamb\u00e9m operam em regime de coreografia, tornando o entendimento do comportamento din\u00e2mico mais dif\u00edcil.\n

Algumas verdades inconvenientes<\/h2>\n

Um sistema n\u00e3o pode ser composto apenas por componentes est\u00e1veis. Partes do software que precisam ser adaptadas com mais frequ\u00eancia devem ser aquelas com menor acoplamento aferente e maior acoplamento eferente, logo, com menos abstra\u00e7\u00f5es.<\/p>\n

Algumas implica\u00e7\u00f5es da an\u00e1lise do acoplamento s\u00e3o:<\/p>\n

    \n
  • O frontend\u00a0<\/em>das aplica\u00e7\u00f5es \u00e9, geralmente, o conjunto de componentes que mais demanda adapta\u00e7\u00f5es, por isso, geralmente, n\u00e3o \u00e9 bom local para solu\u00e7\u00f5es mais sofisticadas e abstra\u00e7\u00f5es inteligentes.<\/li>\n
  • APIs externas, embora menos demandantes de adapta\u00e7\u00f5es, tamb\u00e9m precisam ser inst\u00e1veis para a maioria dos dom\u00ednios, por isso n\u00e3o devem ser projetadas para ter alto acoplamento aferente. Assim, quase sempre \u00e9 prefer\u00edvel, por exemplo, desenvolver uma API externa para atender desktop<\/em> e outra para dispositivos m\u00f3veis, movendo a parte “est\u00e1vel” para uma camada de APIs internas.<\/li>\n
  • N\u00e3o “fechar” com algumas tecnologias – como bancos de dados, por exemplo – introduz a necessidade de abstra\u00e7\u00f5es que, naturalmente, tem complexidade aferente mais alta e acabam dificultando o evolvability.<\/em><\/li>\n
  • Abstra\u00e7\u00f5es em demasia s\u00e3o demonstra\u00e7\u00f5es expl\u00edcitas de ingenuidade inteligente.<\/li>\n<\/ul>\n

    Para toda jornada \u00e9 necess\u00e1rio ter o n\u00edvel adequado de “bagagem”<\/h2>\n

    Acoplamento \u00e9 inevit\u00e1vel mas, sem os cuidados adequados, pode atingir n\u00edveis insustent\u00e1veis. Criar “pontos de acoplamento” \u00e9 f\u00e1cil e, depois disso, remover \u00e9 dif\u00edcil.<\/p>\n

    Arquiteturas de software de qualidade s\u00e3o, acima de tudo, aquelas que evoluem mitigando necessidades para o acoplamento. Al\u00e9m disso, \u00e9 parte das pr\u00e1ticas de arquitetura de software monitorar e estabelecer estrat\u00e9gias para lidar com o acoplamento quando ele surgir. Entretanto, n\u00e3o ignoremos o fato que toda escolha implica em uma ren\u00fancia. Sempre haver\u00e3o\u00a0trade-offs.\u00a0<\/em>Nada \u00e9 bom para tudo!\u00a0<\/strong>Reduzir o acoplamento aferente implica, muitas vezes, em introduzir abstra\u00e7\u00f5es, o que aumenta a complexidade pela dimensionalidade e pela irreversibilidade.<\/p>\n

    <\/p>\n

     <\/p>\n

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

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

      \n
    • A estrat\u00e9gia de modularidade do software em que voc\u00ea est\u00e1 trabalhando colabora para a mitiga\u00e7\u00e3o de causas para acoplamento?<\/li>\n
    • Os testes automatizados est\u00e3o “exigindo” abstra\u00e7\u00f5es de maneira razo\u00e1vel?<\/li>\n
    • Que artefatos de sua solu\u00e7\u00e3o tem alto n\u00edvel de acoplamento aferente?<\/li>\n
    • Os artefatos com acoplamento aferente tem n\u00edveis adequados de testes automatizados?<\/li>\n
    • As abstra\u00e7\u00f5es com acoplamento aferente mais elevado tem estrat\u00e9gia clara de versionamento?<\/li>\n<\/ul>\n","protected":false},"featured_media":1516,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[],"sessoes":[57],"apendices":[],"capitulos":[27],"class_list":["post-1560","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","sessoes-secao-1","capitulos-capitulo-1-6"],"acf":[],"yoast_head":"\nNunca ignore o acoplamento! \/ Cap\u00edtulo 4 v1.03 - 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\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Nunca ignore o acoplamento! \/ Cap\u00edtulo 4 v1.03 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Acoplamento aferente e eferente O acoplamento “nasce” de diversas formas, mas assume apenas duas naturezas gen\u00e9ricas distintas: aferente e eferente. O acoplamento aferente de um artefato – seja ele um componente, classe, fun\u00e7\u00e3o, etc – surge quando este \u00e9 referenciado por outro. Quando, por exemplo, o c\u00f3digo de uma classe “A” faz refer\u00eancia ao c\u00f3digo […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/\" \/>\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:50:56+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/martijn-baudoin-4h0HqC3K4-c-unsplash.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"768\" \/>\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=\"17 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\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/\",\"name\":\"Nunca ignore o acoplamento! \/ Cap\u00edtulo 4 v1.03 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/martijn-baudoin-4h0HqC3K4-c-unsplash.jpg\",\"datePublished\":\"2021-05-06T12:10:49+00:00\",\"dateModified\":\"2024-01-11T20:50:56+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/martijn-baudoin-4h0HqC3K4-c-unsplash.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/martijn-baudoin-4h0HqC3K4-c-unsplash.jpg\",\"width\":1024,\"height\":768},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#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\":\"Nunca ignore o acoplamento! \/ Cap\u00edtulo 4 v1.03\"}]},{\"@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":"Nunca ignore o acoplamento! \/ Cap\u00edtulo 4 v1.03 - 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\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/","og_locale":"pt_BR","og_type":"article","og_title":"Nunca ignore o acoplamento! \/ Cap\u00edtulo 4 v1.03 - Manual do Arquiteto de Software","og_description":"Acoplamento aferente e eferente O acoplamento “nasce” de diversas formas, mas assume apenas duas naturezas gen\u00e9ricas distintas: aferente e eferente. O acoplamento aferente de um artefato – seja ele um componente, classe, fun\u00e7\u00e3o, etc – surge quando este \u00e9 referenciado por outro. Quando, por exemplo, o c\u00f3digo de uma classe “A” faz refer\u00eancia ao c\u00f3digo […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-11T20:50:56+00:00","og_image":[{"width":1024,"height":768,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/martijn-baudoin-4h0HqC3K4-c-unsplash.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"17 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/","name":"Nunca ignore o acoplamento! \/ Cap\u00edtulo 4 v1.03 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/martijn-baudoin-4h0HqC3K4-c-unsplash.jpg","datePublished":"2021-05-06T12:10:49+00:00","dateModified":"2024-01-11T20:50:56+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/martijn-baudoin-4h0HqC3K4-c-unsplash.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/martijn-baudoin-4h0HqC3K4-c-unsplash.jpg","width":1024,"height":768},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/nunca-ignore-o-acoplamento-capitulo-4-v1-03\/#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":"Nunca ignore o acoplamento! \/ Cap\u00edtulo 4 v1.03"}]},{"@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\/1560","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=1560"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/1516"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=1560"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=1560"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=1560"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=1560"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=1560"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}