{"id":1797,"date":"2021-05-25T09:46:30","date_gmt":"2021-05-25T12:46:30","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=1797"},"modified":"2024-01-11T18:01:50","modified_gmt":"2024-01-11T21:01:50","slug":"fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/","title":{"rendered":"Fundamentos para arquiteturas baseadas em servi\u00e7os \/ Cap\u00edtulo 7 v 1.01"},"content":{"rendered":"A arquitetura de um software, muito al\u00e9m dos aspectos t\u00e9cnicos, impacta na din\u00e2mica de trabalho das equipes que o desenvolvem. Boas arquiteturas minimizam os esfor\u00e7os de coordena\u00e7\u00e3o e sincroniza\u00e7\u00e3o entre pessoas e times, colaborando para\u00a0lead times\u00a0<\/em>menores, sem comprometer a qualidade interna.<\/strong>\n
\n

Importante ter clareza que mesmo arquiteturas modulares, se inadequadamente planejadas, n\u00e3o autorizam trabalho paralelo. Arquiteturas tecnicamente particionadas, por exemplo, s\u00e3o mais restritivas do que aquelas particionadas por caracter\u00edsticas do dom\u00ednio.\u00a0<\/strong><\/p>\n

Em arquiteturas tecnicamente particionadas, quando h\u00e1 um time dedicado para cada componente t\u00e9cnico, todos os limites de componentes se convertem em “pontos de coordena\u00e7\u00e3o”. O impacto mais percept\u00edvel ocorre na amplia\u00e7\u00e3o dos lead-times<\/em>.<\/p>\n

\"\"<\/p>\n

Ainda em arquiteturas tecnicamente particionadas, quando os times s\u00e3o organizados por features,<\/em> h\u00e1 “difus\u00e3o de responsabilidade” e queda da qualidade interna que ocasiona, tamb\u00e9m, no longo prazo, preju\u00edzo de lead-time.<\/em><\/p>\n

\"\"<\/p>\nSistemas com arquiteturas particionadas tecnicamente, como em implementa\u00e7\u00f5es mais simples do estilo em camadas, s\u00e3o adequadas para times pequenos, com no m\u00e1ximo 15 pessoas. Em times maiores, arquiteturas precisam ser particionadas pelo dom\u00ednio para serem sustent\u00e1veis. Essa \u00e9 uma das justificativas para desenvolver arquiteturas baseadas em servi\u00e7os.\n

\n
\r\n

Domain-driven Design<\/p>\r\n<\/p>\n

Eric Evans escreveu, em 2003, o livro ‘Domain-driven Design<\/em>‘. Trata-se de uma formaliza\u00e7\u00e3o de pr\u00e1ticas e padr\u00f5es para, segundo o autor, atacara complexidade no cora\u00e7\u00e3o do software.<\/p>\n

Um dos fundamentos de Domain-driven Design<\/em> \u00e9 identificar, dentro de um determinado dom\u00ednio de neg\u00f3cio, subdom\u00ednios que, mais tarde, s\u00e3o modelados em contextos delimitados. Na modelagem de sistemas da forma como apresentamos aqui, cada contexto delimitado pode ser “implementado” como um servi\u00e7o\u00a0<\/div>\n

Difus\u00e3o de responsabilidade<\/h2>\nDesenvolver software \u00e9 um “esporte coletivo” e qualquer atividade em grupo tem demandas de coordena\u00e7\u00e3o.<\/strong> Quanto mais desenvolvedores tocam am um trecho de c\u00f3digo, maiores s\u00e3o as chances de que este c\u00f3digo tenha defeitos e, al\u00e9m disso, maiores s\u00e3o os custos operacionais de gest\u00e3o. Quanto maior o n\u00famero de envolvidos, mais importantes, frequentes e custosas s\u00e3o atividades de comunica\u00e7\u00e3o e de coordena\u00e7\u00e3o.\u00a0<\/strong>Analogamente, mais difusa \u00e9 a responsabilidade pela qualidade.\n
\n

De forma objetiva, um bom\u00a0proxy\u00a0<\/em>para a difus\u00e3o de responsabilidade pode ser obtido pela concentra\u00e7\u00e3o de contribui\u00e7\u00f5es (commits<\/em>) de diversos autores em um determinado artefato, como indicado na f\u00f3rmula abaixo:<\/p>\n

\"\"<\/p>\n

Na f\u00f3rmula\u00a0ai<\/sub><\/em> se refere a cada autor individualmente, nc(ai<\/sub>)<\/em>\u00a0 \u00e9 o n\u00famero de contribui\u00e7\u00f5es para um determinado autor e, finalmente,\u00a0NC\u00a0<\/em>\u00e9 o n\u00famero total de contribui\u00e7\u00f5es. Artefatos mantidos por um \u00fanico autor tem difus\u00e3o de responsabilidade zerada.<\/p>\n

\r\n

Git como 'rede social'<\/p>\r\n<\/p>\n

Ferramentas modernas de controle de vers\u00e3o s\u00e3o frequentemente usadas apenas como mecanismos sofisticados de backup\u00a0<\/em>de c\u00f3digo-fonte. Entretanto, podem ser bem mais do que isso.<\/strong><\/p>\n

\n

O Git, por exemplo, consegue apontar arquivos que s\u00e3o modificados com mais frequ\u00eancia, colaboradores mais ativos, al\u00e9m, \u00e9 claro, par\u00e2metros para c\u00e1lculo da difus\u00e3o de responsabilidade. A instru\u00e7\u00e3o 'git shortlog -s'<\/code>, por exemplo, relaciona a quantidade de commits\u00a0<\/i>, por desenvolvedor, em uma determinada pasta.
\n<\/div>\n

Artefatos com indicadores altos de difus\u00e3o de responsabilidade geralmente apresentam qualidade interna mais baixa.<\/strong> A regra geral predominante parece ser “o que \u00e9 responsabilidade de todos, n\u00e3o \u00e9 de ningu\u00e9m”. No fim, adapta\u00e7\u00f5es acabam sendo implantadas de maneira descuidada causando problemas em produ\u00e7\u00e3o.<\/p>\nCuriosamente, artefatos com maior difus\u00e3o de responsabilidade costumam ser, tamb\u00e9m, aqueles que tem maior acoplamento eferente e que, por isso, quebram com mais facilidade, ou com maior acoplamento aferente, com potencial para gerar preju\u00edzos maiores no sistema, caso apresentem defeito.\n

\nArquiteturas particionadas por dom\u00ednio tendem a ter artefatos com difus\u00e3o de responsabilidade mais baixa.<\/strong> Artefatos com difus\u00e3o de responsabilidade mais baixa tendem a ser mais f\u00e1ceis de manter e evoluir, o que converte essa m\u00e9trica em uma boa fitness function.<\/em>\n
\n

Propriedade sobre artefatos<\/h2>\n

A atribui\u00e7\u00e3o de “propriedade” para artefatos de um software – como documenta\u00e7\u00e3o, c\u00f3digo, banco de dados, etc – \u00e9 um tema controverso.\u00a0Muitas pessoas associam “propriedade” como justificativa para redu\u00e7\u00e3o da colabora\u00e7\u00e3o ou, pior ainda, forma\u00e7\u00e3o de silos. Entretanto, esse n\u00e3o \u00e9 o ponto! A atribui\u00e7\u00e3o de “propriedade” \u00e9 uma medida para tentar minimizar os efeitos da difus\u00e3o de responsabilidades.\u00a0<\/strong><\/p>\n

Atribuir “propriedade” de artefatos a times ou indiv\u00edduos \u00e9 similar a iniciativa de atribuir mantenedores para projetos\u00a0open source.<\/em> Ou seja, determinar responsabilidade pela qualidade atual e futura de um artefato para algu\u00e9m que ir\u00e1 o “zelar e protejer”.<\/p>\n

A “propriedade” de artefatos n\u00e3o \u00e9 uma maneira de coibir contribui\u00e7\u00f5es, muito pelo contr\u00e1rio, \u00e9 um incentivo para participa\u00e7\u00e3o ativa. Cabe aos “propriet\u00e1rios” arbitrar, apenas, que contribui\u00e7\u00f5es est\u00e3o prontas para serem aceitas.<\/p>\n

Particionando a “camada de neg\u00f3cio” em servi\u00e7os<\/h2>\n

A evolu\u00e7\u00e3o dos modelos de opera\u00e7\u00e3o e distribui\u00e7\u00e3o de software, associado com o desenvolvimento de t\u00e9cnicas mais apropriadas de an\u00e1lise de dom\u00ednios de neg\u00f3cios, autorizaram a decomposi\u00e7\u00e3o das tradicionais “camadas de neg\u00f3cios” em contextos delimitados, distribu\u00eddos como servi\u00e7os.<\/p>\n

\"\"<\/p>\n

Nesse modelo, os servi\u00e7os s\u00e3o desenvolvidos e distribu\u00eddos de forma “quase independente”, exceto por serem todos acoplados a um \u00fanico banco de dados monol\u00edtico.<\/p>\nOs servi\u00e7os, individualmente, tendem a ter difus\u00e3o de responsabilidade mais baixa, enquanto o banco de dados e a interface com usu\u00e1rio, al\u00e9m de acoplamento aferente e eferente maiores, tendem a ter difus\u00e3o de responsabilidade mais alta.<\/strong> Nesses cen\u00e1rios, n\u00e3o \u00e9 incomum que a base de dados (e a interface com o usu\u00e1rio) passem a ter controle direto de um time especialista, com “senso de propriedade” suficiente para manter, via burocracia, qualidade interna mais alta.\n

\n

Para serem vi\u00e1veis, tais arquiteturas s\u00e3o constitu\u00eddas por poucos servi\u00e7os.<\/strong> Geralmente, n\u00e3o menos do que 4 e n\u00e3o mais do que 12.<\/p>\n

\r\n

O problema com 'Kernel<\/em> Compartilhado'<\/p>\r\n<\/p>\n

Domain-driven\u00a0<\/em>Design\u00a0<\/em>autoriza a identifica\u00e7\u00e3o e implementa\u00e7\u00e3o de\u00a0kernels\u00a0<\/i>compartilhados: parte do modelo de dom\u00ednio de uso comum para dois ou mais contextos delimitados. Entretanto, antes de solu\u00e7\u00e3o, este tipo de artefato representa problema.<\/p>\n

Kernels\u00a0<\/em>compartilhados s\u00e3o naturalmente acoplados (de maneira aferente) e nascem com difus\u00e3o de responsabilidade alta. Eventualmente, representam redu\u00e7\u00e3o dos custos de desenvolvimento, mas, seguramente, representam acr\u00e9scimo no custo de manuten\u00e7\u00e3o.<\/p>\n

<\/div>\n

Particionando a “interface com o usu\u00e1rio”<\/h2>\n

Uma forma de reduzir os impactos do aumento crescente do acoplamento eferente na interface com o usu\u00e1rio \u00e9 particion\u00e1-la tamb\u00e9m, reduzindo indiretamente os riscos de difus\u00e3o de responsabilidade.<\/p>\nN\u00e3o \u00e9 raro que diferentes perfis de usu\u00e1rios demandem e valorizem caracter\u00edsticas diferentes de usabilidade.<\/strong> Por exemplo, enquanto vendedores tendem a valorizar simplicidade e objetividade, analistas financeiros geralmente gostam dor maior volume de informa\u00e7\u00f5es concentrado (com menos espa\u00e7os em branco). Por isso, antes de ser um problema, o particionamento da interface pode ser uma “solu\u00e7\u00e3o” para a inclus\u00e3o de adapta\u00e7\u00f5es, com coes\u00e3o de padr\u00f5es de projeto de UX.\n

\n

\"\"<\/p>\n

O particionamento da interface com o usu\u00e1rio geralmente segue os mesmos crit\u00e9rios de dom\u00ednio aplicados nos servi\u00e7os na “camada de neg\u00f3cios”.<\/p>\n

A “emerg\u00eancia” das APIs externas<\/h2>\nEventualmente, servi\u00e7os internos ir\u00e3o interagir diretamente com sistemas de terceiros que ir\u00e3o oferecer uma “interface alternativa” para alguns “servi\u00e7os de neg\u00f3cios” de um software. Nesses casos, pode ser uma boa ideia oferecer um servi\u00e7o espec\u00edfico para atender \u00e0s demandas desse servi\u00e7o externo, reduzindo acoplamento eferente externo (e as chances de quebra).\n
\n

\"\"<\/p>\n

Prover uma API externa tamb\u00e9m \u00e9 um bom caminho para reduzir a difus\u00e3o de responsabilidade de integra\u00e7\u00f5es cr\u00edticas e proteger o neg\u00f3cio.<\/p>\n

A “emerg\u00eancia” de uma camada de API (gateway ou proxy)<\/h2>\n

Caso exista necessidade crescente de fazer acesso externo aos servi\u00e7os de dom\u00ednio, al\u00e9m da API externa, \u00e9 uma boa pr\u00e1tica adicionar uma camada com um\u00a0<\/em>proxy\u00a0<\/em>reverso ou\u00a0gateway.<\/em><\/p>\n

\"\"<\/p>\n

O gateway\u00a0<\/em>reduz o acoplamento aferente dos servi\u00e7os e tamb\u00e9m \u00e9 um bom mecanismo para consolidar demandas por m\u00e9tricas, seguran\u00e7a, bilhetagem, auditoria e descoberta.<\/p>\n

Particionando logicamente o “banco de dados”<\/h2>\nA decomposi\u00e7\u00e3o da “camada de neg\u00f3cios” em servi\u00e7os e da “camada de interface” em experi\u00eancias independentes, implicam no aumento do acoplamento aferente do banco de dados, o que \u00e9 um problema em potencial, mesmo com o n\u00famero reduzido de servi\u00e7os (geralmente, 7 em arquiteturas assim)<\/strong>. Se n\u00e3o forem feitas de maneira apropriada, altera\u00e7\u00f5es de esquema podem causar problemas nos diversos servi\u00e7os, o que aumenta bastante a necessidade de coordena\u00e7\u00e3o.\n
\n

Uma sa\u00edda r\u00e1pida, costuma ser prover um componente com modelo de persist\u00eancia para ser utilizado nos diversos servi\u00e7os, suficiente para causar falhas no\u00a0build\u00a0<\/em>quando altera\u00e7\u00f5es de esquema forem realizadas. O versionamento do modelo de persist\u00eancia \u00e9 fiel a evolu\u00e7\u00e3o do esquema.<\/p>\n

\"\"<\/p>\n

Em seguida, uma boa ideia \u00e9 recorrer a mecanismos para particionar logicamente o banco de dados criando modelos de persist\u00eancia decompostos pelos diferentes contextos delimitados. Modernamente, recursos como particionamento vertical, permitem a administra\u00e7\u00e3o de bases de maneira inteligente, melhorando a performance.<\/strong><\/p>\n

\"\"<\/p>\n

O particionamento vertical, eventualmente, demandar\u00e1 um componentes com modelos de persist\u00eancia tamb\u00e9m particionados para serem utilizados nos diversos servi\u00e7os, suficientes para causar falhas no build\u00a0<\/em>quando altera\u00e7\u00f5es de esquema forem realizadas. O versionamento do modelo de persist\u00eancia \u00e9 fiel a evolu\u00e7\u00e3o do esquema.<\/p>\n

Particionando fisicamente o “banco de dados”<\/h2>\n

Eventualmente, h\u00e1 possibilidades para particionar um banco de dados monol\u00edtico em inst\u00e2ncias independentes, alinhadas ao dom\u00ednio, de forma semelhante ao que ocorre com microsservi\u00e7os.<\/p>\n

\"\"<\/p>\nO ponto importante, aqui, \u00e9 garantir que cada banco de dados n\u00e3o seja necess\u00e1rio para outros servi\u00e7os e, tamb\u00e9m, duplica\u00e7\u00e3o de dados, exceto quando isso for natural<\/strong>. Excepcionalmente, o particionamento das bases de dados pode ser justificada por problemas de performance.\n

\n

Conway, outra vez!<\/h2>\n

O particionamento pelo dom\u00ednio permite a organiza\u00e7\u00e3o dos times em torno de componentes coesos, com baixa difus\u00e3o de responsabilidade.<\/p>\n

Em primeira an\u00e1lise, cada servi\u00e7o pode ser mantido por um time independente, que \u00e9 “consumido” pelo time que elabora a interface e “consome” um time de DBAs respons\u00e1vel pelo banco de dados. Eventulamente, o time de banco de dados pode ser tamb\u00e9m particionado conforme o servi\u00e7o, bem como a interface.<\/p>\n

Indica\u00e7\u00f5es e contraindica\u00e7\u00f5es<\/h2>\nA abordagem arquitetural disposta nesse cap\u00edtulo destaca-se pelo pragmatismo.<\/strong> Embora, como arquitetura distribu\u00edda, a decomposi\u00e7\u00e3o em poucos servi\u00e7os seja menos “ambiciosa” do que abordagens mais extremas, como microsservi\u00e7os, trata-se de um modelo “mais f\u00e1cil de pagar”.\n
\nA decomposi\u00e7\u00e3o por contextos tem\u00a0fit\u00a0<\/em>natural com an\u00e1lises baseadas em\u00a0Domain-driven Design<\/em>. Al\u00e9m disso, a “toler\u00e2ncia” a um banco de dados monol\u00edtico autoriza transa\u00e7\u00f5es ACID.\n
\nParticionar componentes, em \u00faltima inst\u00e2ncia, demanda times particionados. Por isso, essa abordagem n\u00e3o \u00e9 apropriada para times pequenos ou monol\u00edticos. Assumindo, ali\u00e1s, que o tamanho ideal de times de tecnologia \u00e9 de 7 pessoas e que haver\u00e1 um time para cada servi\u00e7o, podemos inferir que este estilo arquitetural funciona bem para equipes de at\u00e9 100 pessoas.<\/strong>\n
\n

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

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

    \n
  • Voc\u00ea conseguiria decompor seu sistema em contextos delimitados claros e independentes?<\/li>\n
  • Quais seriam as dificuldades e facilidades para particionamento da base de dados (l\u00f3gico ou f\u00edsico)?<\/li>\n<\/ul>\n

     <\/p>\n","protected":false},"featured_media":1791,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[],"sessoes":[59],"apendices":[],"capitulos":[31],"class_list":["post-1797","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","sessoes-secao-3","capitulos-capitulo-3-3"],"acf":[],"yoast_head":"\nFundamentos para arquiteturas baseadas em servi\u00e7os \/ Cap\u00edtulo 7 v 1.01 - 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\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Fundamentos para arquiteturas baseadas em servi\u00e7os \/ Cap\u00edtulo 7 v 1.01 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Importante ter clareza que mesmo arquiteturas modulares, se inadequadamente planejadas, n\u00e3o autorizam trabalho paralelo. Arquiteturas tecnicamente particionadas, por exemplo, s\u00e3o mais restritivas do que aquelas particionadas por caracter\u00edsticas do dom\u00ednio.\u00a0 Em arquiteturas tecnicamente particionadas, quando h\u00e1 um time dedicado para cada componente t\u00e9cnico, todos os limites de componentes se convertem em “pontos de coordena\u00e7\u00e3o”. O […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/\" \/>\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:01:50+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/kelly-sikkema-v9FQR4tbIq8-unsplash.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"683\" \/>\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=\"10 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\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/\",\"name\":\"Fundamentos para arquiteturas baseadas em servi\u00e7os \/ Cap\u00edtulo 7 v 1.01 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/kelly-sikkema-v9FQR4tbIq8-unsplash.jpg\",\"datePublished\":\"2021-05-25T12:46:30+00:00\",\"dateModified\":\"2024-01-11T21:01:50+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/kelly-sikkema-v9FQR4tbIq8-unsplash.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/kelly-sikkema-v9FQR4tbIq8-unsplash.jpg\",\"width\":1024,\"height\":683},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#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\":\"Fundamentos para arquiteturas baseadas em servi\u00e7os \/ Cap\u00edtulo 7 v 1.01\"}]},{\"@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":"Fundamentos para arquiteturas baseadas em servi\u00e7os \/ Cap\u00edtulo 7 v 1.01 - 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\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/","og_locale":"pt_BR","og_type":"article","og_title":"Fundamentos para arquiteturas baseadas em servi\u00e7os \/ Cap\u00edtulo 7 v 1.01 - Manual do Arquiteto de Software","og_description":"Importante ter clareza que mesmo arquiteturas modulares, se inadequadamente planejadas, n\u00e3o autorizam trabalho paralelo. Arquiteturas tecnicamente particionadas, por exemplo, s\u00e3o mais restritivas do que aquelas particionadas por caracter\u00edsticas do dom\u00ednio.\u00a0 Em arquiteturas tecnicamente particionadas, quando h\u00e1 um time dedicado para cada componente t\u00e9cnico, todos os limites de componentes se convertem em “pontos de coordena\u00e7\u00e3o”. O […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-11T21:01:50+00:00","og_image":[{"width":1024,"height":683,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/kelly-sikkema-v9FQR4tbIq8-unsplash.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"10 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/","name":"Fundamentos para arquiteturas baseadas em servi\u00e7os \/ Cap\u00edtulo 7 v 1.01 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/kelly-sikkema-v9FQR4tbIq8-unsplash.jpg","datePublished":"2021-05-25T12:46:30+00:00","dateModified":"2024-01-11T21:01:50+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/kelly-sikkema-v9FQR4tbIq8-unsplash.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2021\/05\/kelly-sikkema-v9FQR4tbIq8-unsplash.jpg","width":1024,"height":683},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos-capitulo-7-v-1-01\/#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":"Fundamentos para arquiteturas baseadas em servi\u00e7os \/ Cap\u00edtulo 7 v 1.01"}]},{"@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\/1797","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=1797"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/1791"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=1797"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=1797"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=1797"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=1797"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=1797"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}