{"id":2823,"date":"2021-07-19T10:06:22","date_gmt":"2021-07-19T13:06:22","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=2823"},"modified":"2024-01-12T11:38:33","modified_gmt":"2024-01-12T14:38:33","slug":"em-busca-da-assertividade-na-pratica-arquitetural","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/","title":{"rendered":"Cap 6.1 Em busca da assertividade na pr\u00e1tica arquitetural \/ Cap\u00edtulo 15 v 1.02"},"content":{"rendered":"A boa arquitetura de software \u00e9 a arte de resolver trade-offs<\/em>.<\/strong>\n
\n

N\u00e3o h\u00e1 padr\u00e3o, estilo ou solu\u00e7\u00e3o “bala de prata”.<\/strong> Toda decis\u00e3o implica em vantagens e desvantagens marcantes. Priorizar resili\u00eancia sacrifica performance. Melhorar a seguran\u00e7a pode comprometer disponibilidade. Combater o acoplamento frequentemente vai na dire\u00e7\u00e3o contr\u00e1ria do reuso. N\u00e3o h\u00e1 almo\u00e7o gr\u00e1tis!<\/strong><\/p>\nN\u00e3o se pode perder de vista que o objetivo das pr\u00e1ticas de arquitetura de software \u00e9, sempre, atender as expectativas do neg\u00f3cio, respeitando restri\u00e7\u00f5es e atingir atributos de qualidade, tudo isso com o menor custo poss\u00edvel, mitigando riscos. A melhor solu\u00e7\u00e3o arquitetural geralmente ser\u00e1 aquela que tiver a melhor rela\u00e7\u00e3o de custo e risco, conforme o contexto.<\/strong>\n

O que entender por assertividade?<\/h2>\nAssertividade, para o projeto de arquitetura, implica em tr\u00eas cuidados simples: garantir que decis\u00f5es arquiteturais sejam tomadas, justificar adequadamente essas decis\u00f5es e, finalmente, comunicar adequadamente tanto as decis\u00f5es quanto suas justificativas.\n
\n

Para boa parte dos problemas arquiteturais h\u00e1 pelo menos duas abordagens de solu\u00e7\u00e3o. Assumir decis\u00f5es implica, fatalmente, em ren\u00fancias. N\u00e3o raro, por esse motivo, decis\u00f5es ficam sendo postergadas muito al\u00e9m do \u00faltimo momento respons\u00e1vel.<\/p>\nUma defini\u00e7\u00e3o simples de ansiedade diz que esta \u00e9 causada pelo “excesso de futuro”. Ou seja, pelos diversos “caminhos poss\u00edveis” frente a pontos de decis\u00e3o. Quando decis\u00f5es arquiteturais s\u00e3o adiadas, acabam “plantando” ansiedade n\u00e3o apenas nos times t\u00e9cnicos mas tamb\u00e9m nos demais stakeholders<\/em>. Infelizmente, para complicar ainda mais as coisas, podemos dizer que a procrastina\u00e7\u00e3o \u00e9 a prima irm\u00e3 da ansiedade.\n

\n

Cabe aos arquitetos de sotware a responsabilidade de garantir que decis\u00f5es arquiteturais sejam tomadas no melhor momento.\u00a0<\/strong>Isso feito, previnindo a ansiedade dos times t\u00e9cnicos e garantindo fluxo de entrega de valor.<\/p>\n

Todas as decis\u00f5es arquiteturais tamb\u00e9m precisam ser claramente justificadas. Ou seja, \u00e9 importante que, al\u00e9m de comunicar a decis\u00e3o arquitetural, tamb\u00e9m seja compartilhado o racional que levou a essa decis\u00e3o. Isso ser\u00e1, como j\u00e1 sabemos, de enorme valia mais tarde, quando essas decis\u00f5es forem questionadas.<\/p>\n

\r\n

Request for Comments (RFC)<\/p>\r\n<\/p>\n

Uma maneira efetiva de registrar decis\u00f5es arquiteturais, como j\u00e1 sabemos, \u00e9 utilizando ADRs.<\/p>\n

Decis\u00f5es arquiteturais nas quais se entende haver necessidade de delibera\u00e7\u00e3o podem ser registradas com o status\u00a0<\/em>de RFC, estabelecendo, tamb\u00e9m, um\u00a0deadline<\/em>.<\/p>\n

RFCs podem ser mantidas em Issues\u00a0<\/em>no Github, por exemplo.<\/p>\n

<\/div>\n

Finalmente, \u00e9 importante que se busquem, sempre, meios apropriados para comunicar decis\u00f5es arquiteturais. Mandar um e-mail n\u00e3o basta!<\/strong><\/p>\n

O sens\u00edvel equil\u00edbrio entre risco e custo<\/h2>\nH\u00e1 duas vari\u00e1veis extremamente importantes na avalia\u00e7\u00e3o do contexto para as pr\u00e1ticas arquiteturais: sensibilidade ao custo e sensibilidade ao risco.<\/strong> Geralmente, quanto maior a sensibilidade ao risco, menor deve ser a sensibilidade ao custo.\n
\n

A toler\u00e2ncia ou a necessidade de assumir riscos implica naturalmente nas pr\u00e1ticas e processos de arquitetura. Muitas vezes, “exageros” processuais s\u00e3o necess\u00e1rios para mitigar riscos. Outra abordagem \u00e9 acentuar a senioridade. Ambas linhas de atua\u00e7\u00e3o s\u00e3o ofensivas ao custo.<\/p>\n

Cada projeto enfrenta diferentes riscos, logo, n\u00e3o h\u00e1 n\u00e3o h\u00e1 uma \u00fanica forma certa de conduzir os processos arquiteturais. Quando o risco \u00e9 extremamente baixo, as decis\u00f5es arquiteturais s\u00e3o mais simples.<\/p>\n

Reduzir custos s\u00f3 pode ser foco quando a incerteza, logo o risco, \u00e9 m\u00ednimo.<\/p>\n

O problema da “arquitetura limpa”<\/h2>\n

De tempos em tempos surgem “receitas de bolo” para a elabora\u00e7\u00e3o de arquiteturas. Elas emergem a despeito de seus proponentes e se estabelecem como o “jeito certo” de organizar componentes, distribuir responsabilidades e estabelecer rela\u00e7\u00f5es. J\u00e1 foi assim com a “arquitetura hexagonal”, tamb\u00e9m foi assim com “microsservi\u00e7os” e, recentemente, est\u00e1 sendo assim com a “mania” da arquitetura limpa – uma forma de organizar sistemas em camadas propostas por Robert Martin.<\/p>\n

\"Implementando<\/p>\nNa pr\u00e1tica, a “arquitetura limpa” proposta pelo “Uncle Bob” \u00e9 uma releitura opinativa do estilo em camadas. Ela \u00e9 \u00fatil para, provavelmente para a grande maioria dos cen\u00e1rios de desenvolvimento, em times pequenos ou m\u00e9dios, para solu\u00e7\u00f5es menores e bem isoladas. \u00c9 um “jeito certo” para fazer software, mas est\u00e1 longe de ser o “\u00fanico jeito certo”. Ali\u00e1s, \u00e9, sem d\u00favidas, o “jeito errado” para cen\u00e1rios complexos, com times grandes, que demandam, por exemplo, microsservi\u00e7os.<\/strong>\n

Principais desafios para a assertividade<\/h2>\n

Predile\u00e7\u00e3o por modismos<\/h4>\n

O favoritismo por estilos arquiteturais muda de tempos em tempos.<\/strong> Eventualmente, os “pontos de dor” dos estilos arquiteturais vigentes s\u00e3o mitigados em novas propostas. \u00c9 o caso, por exemplo, do “desacoplamento extremo” dos microsservi\u00e7os confrontado com camadas. A tend\u00eancia ao reuso do passado foi sendo substitu\u00edda pelo desejo de criar componentes com baixo acoplamento. Tudo \u00e9 transit\u00f3rio.<\/strong><\/p>\n

Tecnologias que mudam<\/h4>\n

As verdades de ontem sequer s\u00e3o consideradas hoje.<\/strong> H\u00e1 relativamente pouco tempo, sequer existiam ferramentas como Kubernetes<\/a> ou Docker<\/a>, embora cont\u00eaineres fossem tecnicamente poss\u00edvel h\u00e1 d\u00e9cadas. Em alguns anos, Docker<\/a> e Kubernetes<\/a> tamb\u00e9m ser\u00e3o tecnologias ultrapassadas.<\/p>\n

… r\u00e1pido<\/h4>\n

Nos anos recentes, ali\u00e1s, n\u00e3o s\u00f3 a mudan\u00e7a \u00e9 uma certeza, mas tamb\u00e9m est\u00e1 cada vez mais acelerada.<\/strong> O sentimento de “melhor ferramenta\/tecnologia\/paradigma de todos os tempos da \u00faltima semana” com frequ\u00eancia causa desgaste sem compensa\u00e7\u00f5es razo\u00e1veis para o neg\u00f3cio.<\/p>\n

Escopos (de dom\u00ednio) cada vez mais complexos<\/h4>\n

Cada vez mais, se espera software mais onipresente, inteligente e integrado. Ali\u00e1s, software melhor tem autorizado pr\u00e1ticas mais complexas no dom\u00ednio, que por sua vez tem demandado software ainda melhor, em um ciclo as vezes virtuoso, outras vezes vicioso.<\/p>\nDe fato, as expectativas em torno do software crescem em ritmo acelerado exigindo a ado\u00e7\u00e3o de n\u00edveis de abstra\u00e7\u00e3o cada vez mais altos no desenvolvimento de sistemas. N\u00e3o raro, projetar software parece “montar lego” pela predomin\u00e2ncia de componentes prontos, principalmente na utiliza\u00e7\u00e3o da nuvem.\n

Ambientes (potencialmente) hostis<\/h4>\n

Em contextos controlados, mudan\u00e7as nas regula\u00e7\u00f5es implicam em desafios para cumprimento de prazos que, frequentemente, ignoram as dificuldades na atualiza\u00e7\u00e3o dos sistemas.<\/p>\n

Sistemas dependentes em demasia de componentes externos podem ser fortemente impactos com ajustes de pol\u00edticas comerciais ou com custos de licenciamento.<\/p>\n

Estruturas organizacionais doentes ou inadequadas podem impossibilitar a utiliza\u00e7\u00e3o de estilos arquiteturais como desdobramento da lei de Conway.<\/p>\n

Identificando e adotando “abordagens certas”<\/h2>\n

Arquitetos, como \u201ctrabalhadores do conhecimento\u201d, trabalham para \u201cresolver problemas\u201d. <\/b>Todo conjunto de demandas que justifica sistemas pode ser descrito como um conjunto de problemas que esperam solu\u00e7\u00f5es.<\/p>\nPadr\u00f5es e estilos arquiteturais s\u00e3o abstra\u00e7\u00f5es de solu\u00e7\u00f5es recorrentes para problemas comuns. Entretanto, para serem efetivos, devem ser escolhidos a luz de suas for\u00e7as e fraquezas relacionadas, sobretudo, ao contexto.\n

\n

Saber reconhecer a \u201cnatureza\u201d de um problema ajuda a definir a estrat\u00e9gia mais efetiva para o resolver, maximizando o desempenho\/resultado e minimizando o esfor\u00e7o\/trabalho. Os cinco dom\u00ednios do framework Cynefin – um framework\u00a0<\/em>desenvolvido por David Snowden na IBM – ajudam na classifica\u00e7\u00e3o de problemas, direcionando abordagem para solu\u00e7\u00e3o.<\/p>\n

<\/p>\n

A proposta central do framework Cynefin \u00e9 classificar problemas em cinco dom\u00ednios diferentes.<\/p>\n

O primeiro dom\u00ednio, \u201c\u00d3bvio\u201d ou \u201cSimples\u201d, \u00e9 aquele ao qual pertencem os problemas que tem clara rela\u00e7\u00e3o entre causa e efeito.<\/strong> Sabe-se, com relativa precis\u00e3o, qual a\u00e7\u00e3o precisa ser realizada para atingir um determinado resultado.\u00a0<\/b>Problemas desse dom\u00ednio podem ser corrigidos, evitados ou mitigados atrav\u00e9s da aplica\u00e7\u00e3o de melhores pr\u00e1ticas. Al\u00e9m disso, quem os tratar\u00e1 precisa apenas de treinamento e capacidade anal\u00edtica para detectar, categorizar e aplicar solu\u00e7\u00f5es. Raramente ser\u00e1 o caso na arquitetura de software. Eventualmente, no desenvolvimento de ferramentas utilit\u00e1rias.<\/strong><\/p>\n

O segundo dom\u00ednio, \u201cComplicado\u201d, \u00e9 aquele ao qual pertencem os problemas que tamb\u00e9m tem rela\u00e7\u00e3o clara entre causa e efeito, por\u00e9m, geralmente, onde diferentes a\u00e7\u00f5es podem atingir um mesmo resultado<\/strong>. Problemas desse dom\u00ednio s\u00e3o, geralmente, melhor resolvidos por pessoas com experi\u00eancia, que conseguem julgar os pr\u00f3s e contras de diversas alternativas e escolher o que \u00e9 mais adequado ao contexto. Problemas complicados s\u00e3o comuns no design<\/em> n\u00e3o arquitetural.<\/strong><\/p>\n

O terceiro dom\u00ednio, \u201cComplexo\u201d, \u00e9 aquele onde tamb\u00e9m \u00e9 poss\u00edvel estabelecer rela\u00e7\u00e3o de causa e efeito. Entretanto, apenas depois de aplicada uma a\u00e7\u00e3o<\/strong>. Esses s\u00e3o aqueles problemas que precisam de experimenta\u00e7\u00e3o para serem resolvidos. Afinal, o n\u00famero de vari\u00e1veis \u00e9 t\u00e3o grande que impossibilita previs\u00e3o 100% segura. Nesse dom\u00ednio encontra-se, por exemplo, o desenvolvimento de neg\u00f3cios e a maioria dos desafios arquiteturais.\u00a0<\/strong><\/p>\n

O quarto dom\u00ednio, \u201cCa\u00f3tico\u201d, \u00e9 aquele onde n\u00e3o \u00e9 poss\u00edvel determinar, com clareza, rela\u00e7\u00f5es de causa e efeito, nem antes, nem depois de adotada uma a\u00e7\u00e3o.<\/strong> S\u00e3o problemas onde o n\u00famero de vari\u00e1veis \u00e9 muito grande e \u00e9 imposs\u00edvel de determinar causalidades. Problemas desse dom\u00ednio costumam ocorrer em situa\u00e7\u00f5es at\u00edpicas, geralmente associadas a circunst\u00e2ncias cr\u00edticas. Sistemas distribu\u00eddos elaborados de maneira descuidada tendem ao caos. Sistemas ca\u00f3ticos podem ser “influenciados”, mas nunca “determinados”.<\/strong><\/p>\n

Categorias diferentes de problemas exigem abordagens diferentes para determinar uma solu\u00e7\u00e3o.<\/b><\/p>\n

Abordagens complicadas n\u00e3o suportam solu\u00e7\u00f5es complexas<\/h4>\n

A \u201cmentalidade bin\u00e1ria\u201d empregada para resolver problemas \u201c\u00f3bvios\u201d geralmente conduz a paralisia por an\u00e1lise em cen\u00e1rios complexos. Afinal, cen\u00e1rios \u201c\u00f3bvios\u201d s\u00e3o resolvidos com conhecimento e \u201cfor\u00e7a bruta\u201d, enquanto cen\u00e1rios \u201ccomplexos\u201d s\u00f3 podem ser resolvidos com \u201ctentativa-aprendizado-e-erro\u201d.<\/p>\n

A urg\u00eancia de pr\u00e1ticas \u00e1geis<\/h4>\n

\u00c9 a natureza complexa do neg\u00f3cio que \u00e9 a respons\u00e1vel por n\u00e3o ser poss\u00edvel que metodologias \u201ccascata\u201d funcionem para o desenvolvimento de software. Metodologias \u00e1geis s\u00e3o uma tentativa de facilitar experimenta\u00e7\u00e3o durante o desenvolvimento de software, sem comprometer efici\u00eancia.<\/p>\n

Principais aspectos influenciadores<\/h2>\n

Na pr\u00e1tica, as dificuldades das decis\u00f5es arquiteturais s\u00e3o mitigadas pela redu\u00e7\u00e3o da quantidade de vari\u00e1veis (dimensionalidade) que podem influenciar na tomada de decis\u00f5es arquiteturais.<\/strong> Quanto menos “aspectos discut\u00edveis”, mais delimitadas s\u00e3o as alternativas que precisam ser consideradas e mais assertivas s\u00e3o as decis\u00f5es.<\/p>\n

Sabendo-se, por exemplo, que o objetivo n\u00e3o \u00e9 “escalar times”, descarta-se a utiliza\u00e7\u00e3o de microsservi\u00e7os. Quando times n\u00e3o podem ser “tecnicamente” apartados, descarta-se a ado\u00e7\u00e3o de modelos simples de camadas. Logo, estrutura organizacional, considerando tamanho e forma de organizar os times s\u00e3o dois aspectos influenciadores fundamentais.<\/strong><\/p>\n

A forma como os dados est\u00e3o sendo gerenciados na organiza\u00e7\u00e3o tamb\u00e9m \u00e9 impactante<\/strong>. Dom\u00ednios que demandam “dados quentes” para organiza\u00e7\u00e3o t\u00e1tica e estrat\u00e9gica s\u00e3o menos tolerantes para sistemas distribu\u00eddos e tamb\u00e9m tendem a n\u00e3o suportar bem a escala. Dados centralizados se convertem em gargalo. Dados distribu\u00eddos oferecem desafios a consist\u00eancia.<\/p>\n

Restri\u00e7\u00f5es com fornecedores e regula\u00e7\u00e3o invariavelmente restringem op\u00e7\u00f5es arquiteturais relevantes.\u00a0<\/strong>Se h\u00e1 restri\u00e7\u00f5es de utiliza\u00e7\u00e3o de nuvem, por exemplo, restringe-se consideravelmente a ado\u00e7\u00e3o de componentes prontos.<\/p>\n

Finalmente, \u00e9 importante observar o conhecimento dos times e a familiaridade com naturezas, tanto de problemas, como de designs<\/em> propostos.\u00a0<\/strong>Por exemplo, se uma organiza\u00e7\u00e3o n\u00e3o tem maturidade na ado\u00e7\u00e3o de pr\u00e1ticas \u00e1geis, estilos arquiteturais que dependem dessas pr\u00e1ticas ir\u00e3o ter dificuldades de realiza\u00e7\u00e3o.<\/p>\n

Isomorfismo entre dom\u00ednio e arquitetura<\/h4>\n

Alguns dom\u00ednios de problema parecem ter\u00a0match\u00a0<\/em>perfeito com alguns estilos arquiteturais.<\/strong>\u00a0Pipes and Filters,\u00a0<\/em>por exemplo, encaixam perfeitamente com dom\u00ednios organizados em torno de sequ\u00eancias de atividades bem determinadas. Microkernel<\/em>, outro estilo arquitetural,\u00a0<\/em>\u00e9 perfeito para cen\u00e1rios que demandam customiza\u00e7\u00e3o.<\/p>\n

Por outro lado, h\u00e1 dom\u00ednios de problema que conflitam evidentemente com alguns estilos arquiteturais. <\/strong>Dom\u00ednios que demandam alto n\u00edvel de “acoplamento sem\u00e2ntico” sofrem em estilos extremamente desacoplados ou distribu\u00eddos.<\/p>\n

Sobre a necessidade de assumir d\u00edvidas t\u00e9cnicas<\/h2>\n

D\u00edvidas t\u00e9cnicas<\/a> surgem quando desenvolvedores de software, de forma deliberada ou n\u00e3o, abrem m\u00e3o de boas pr\u00e1ticas de desenvolvimento para ganhar algum tempo. Entretanto, acabam sofrendo, mais tarde, com os custos e tempos de manuten\u00e7\u00e3o mais altos.\u00a0<\/strong>Sob a perspectiva de arquitetura de software, elas acontecem quando decis\u00f5es de design\u00a0<\/em>n\u00e3o \u00f3timas realizadas.<\/p>\n

Os \u201cjuros\u201d resultantes das d\u00edvidas t\u00e9cnicas, para programadores, costumam ficar evidentes em maior dificuldade para ler e entender o c\u00f3digo, fragilidade decorrente de acoplamento (mexer em uma parte do sistema, estraga outra), dificuldade para adicionar features\u00a0<\/em>sem quebrar testes, etc. Para a arquitetura, os “juros” ficam evidentes pela incapacidade de atingir os objetivos do neg\u00f3cio, respeitar restri\u00e7\u00f5es ou atender atributos de qualidade.<\/strong><\/p>\n

\u00c9 sempre importante ressaltar que, se n\u00e3o h\u00e1 \u201cjuro\u201d percebido, provavelmente n\u00e3o h\u00e1 d\u00edvida. <\/strong>Ou seja, se nenhum preju\u00edzo \u00e9 sentido pelo time t\u00e9cnico, ou pelo neg\u00f3cio, por causa de uma decis\u00e3o t\u00e9cnica que aparentava n\u00e3o ser boa, ent\u00e3o, talvez n\u00e3o haja nada de errado com ela!<\/p>\n

N\u00e3o \u00e9 incomum encontrar t\u00e9cnicos\u00a0 implementando solu\u00e7\u00f5es mais \u201csofisticadas\u201d justificando-as por pretensas boas pr\u00e1ticas, mas que, na verdade, adicionam pouco ou nenhum valor ao neg\u00f3cio. Ali\u00e1s, com frequ\u00eancia adicionam apenas complexidade e, consequentemente, custo.<\/p>\n

Se um desenvolvedor ou arquiteto adota uma \u201cboa pr\u00e1tica\u201d sem saber justificar a raz\u00e3o para estar fazendo isso, ent\u00e3o, h\u00e1 chances grandes do efeito ser exatamente o oposto do que planeja.<\/strong>\u00a0Microsservi\u00e7os implementados para viabilizar escalabilidade, mas que n\u00e3o escalam. Reposit\u00f3rios isolando acesso a dados para permitir uma hipot\u00e9tica \u201ctroca do banco\u201d, que nunca ocorre.<\/p>\nQuando todo embasamento que um desenvolvedor ou arquiteto tem para adotar uma pr\u00e1tica \u00e9 a palavra de algu\u00e9m, ent\u00e3o, n\u00e3o tem embasamento algum.\n

As “sementes” das d\u00edvidas t\u00e9cnicas arquiteturais<\/h4>\n

D\u00edvidas t\u00e9cnicas arquiteturais nascem, frequentemente, da necessidade de atender alguma especificidade do neg\u00f3cio. Geralmente, sob uma das seguintes categorias:<\/p>\n

    \n
  1. custo;<\/li>\n
  2. time-to-market;<\/em><\/li>\n
  3. satisfa\u00e7\u00e3o dos usu\u00e1rios;<\/li>\n
  4. posicionamento estrat\u00e9gico.<\/li>\n<\/ol>\n

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

    Antes de avan\u00e7ar, convido-o as seguintes reflex\u00f5es:<\/p>\n

      \n
    1. As solu\u00e7\u00f5es arquiteturais que seu time est\u00e3o adotando s\u00e3o as melhores, sob o ponto de vista de custo e risco?<\/li>\n
    2. Quais s\u00e3o os principais desafios que tens enfrentado para a assertividade nas decis\u00f5es arquiteturais?<\/li>\n
    3. Conforme o Cynefin, qual \u00e9 a categoria dos problemas que tens enfrentado com mais frequ\u00eancia?<\/li>\n
    4. Trabalhou em algum projeto com isomorfismo entre arquitetura e dom\u00ednio?<\/li>\n
    5. Quais s\u00e3o as principais d\u00edvidas t\u00e9cnicas que tens enfrentado em seu projeto recentemente? Elas s\u00e3o arquiteturais?<\/li>\n<\/ol>\n

       <\/p>\n","protected":false},"featured_media":2810,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[72],"sessoes":[60],"apendices":[],"capitulos":[64],"class_list":["post-2823","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","url-permanente","sessoes-secao-6","capitulos-capitulo-6-1"],"acf":[],"yoast_head":"\nCap 6.1 Em busca da assertividade na pr\u00e1tica arquitetural \/ Cap\u00edtulo 15 v 1.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\/em-busca-da-assertividade-na-pratica-arquitetural\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Cap 6.1 Em busca da assertividade na pr\u00e1tica arquitetural \/ Cap\u00edtulo 15 v 1.02 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"N\u00e3o h\u00e1 padr\u00e3o, estilo ou solu\u00e7\u00e3o “bala de prata”. Toda decis\u00e3o implica em vantagens e desvantagens marcantes. Priorizar resili\u00eancia sacrifica performance. Melhorar a seguran\u00e7a pode comprometer disponibilidade. Combater o acoplamento frequentemente vai na dire\u00e7\u00e3o contr\u00e1ria do reuso. N\u00e3o h\u00e1 almo\u00e7o gr\u00e1tis! O que entender por assertividade? Para boa parte dos problemas arquiteturais h\u00e1 pelo menos […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/\" \/>\n<meta property=\"og:site_name\" content=\"Manual do Arquiteto de Software\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/eximiaco\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-12T14:38:33+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/brett-jordan-Fp4ERdkR5jU-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=\"13 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\/em-busca-da-assertividade-na-pratica-arquitetural\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/\",\"name\":\"Cap 6.1 Em busca da assertividade na pr\u00e1tica arquitetural \/ Cap\u00edtulo 15 v 1.02 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/brett-jordan-Fp4ERdkR5jU-unsplash.jpg\",\"datePublished\":\"2021-07-19T13:06:22+00:00\",\"dateModified\":\"2024-01-12T14:38:33+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/brett-jordan-Fp4ERdkR5jU-unsplash.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/brett-jordan-Fp4ERdkR5jU-unsplash.jpg\",\"width\":1024,\"height\":768},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#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 6.1 Em busca da assertividade na pr\u00e1tica arquitetural \/ Cap\u00edtulo 15 v 1.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 6.1 Em busca da assertividade na pr\u00e1tica arquitetural \/ Cap\u00edtulo 15 v 1.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\/em-busca-da-assertividade-na-pratica-arquitetural\/","og_locale":"pt_BR","og_type":"article","og_title":"Cap 6.1 Em busca da assertividade na pr\u00e1tica arquitetural \/ Cap\u00edtulo 15 v 1.02 - Manual do Arquiteto de Software","og_description":"N\u00e3o h\u00e1 padr\u00e3o, estilo ou solu\u00e7\u00e3o “bala de prata”. Toda decis\u00e3o implica em vantagens e desvantagens marcantes. Priorizar resili\u00eancia sacrifica performance. Melhorar a seguran\u00e7a pode comprometer disponibilidade. Combater o acoplamento frequentemente vai na dire\u00e7\u00e3o contr\u00e1ria do reuso. N\u00e3o h\u00e1 almo\u00e7o gr\u00e1tis! O que entender por assertividade? Para boa parte dos problemas arquiteturais h\u00e1 pelo menos […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-12T14:38:33+00:00","og_image":[{"width":1024,"height":768,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/brett-jordan-Fp4ERdkR5jU-unsplash.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"13 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/","name":"Cap 6.1 Em busca da assertividade na pr\u00e1tica arquitetural \/ Cap\u00edtulo 15 v 1.02 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/brett-jordan-Fp4ERdkR5jU-unsplash.jpg","datePublished":"2021-07-19T13:06:22+00:00","dateModified":"2024-01-12T14:38:33+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/brett-jordan-Fp4ERdkR5jU-unsplash.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/07\/brett-jordan-Fp4ERdkR5jU-unsplash.jpg","width":1024,"height":768},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/em-busca-da-assertividade-na-pratica-arquitetural\/#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 6.1 Em busca da assertividade na pr\u00e1tica arquitetural \/ Cap\u00edtulo 15 v 1.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\/2823","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=2823"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/2810"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=2823"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=2823"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=2823"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=2823"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=2823"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}