Tag: dev

Página 1

Página 2

Página 3

A compra deste conteúdo não prevê o atendimento e fornecimento de suporte técnico operacional, instalação ou configuração do sistema de leitor de ebooks. Em alguns casos, e dependendo da plataforma, o suporte poderá ser obtido com o fabricante do equipamento e/ou loja de comércio de ebooks.

Página 4

Elogios para Fundamentos da Arquitetura de Software Neal e Mark não são apenas excelentes arquitetos de software, também são professores excepcionais. Com o livro Fundamentos da arquitetura de software, eles conseguiram condensar o amplo tópico da arquitetura em um trabalho conciso que reflete décadas de experiência. Se você é novo na função ou pratica a arquitetura por anos, este livro o ajudará a ser melhor no seu trabalho. Só gostaria que ele tivesse sido escrito antes na minha carreira.

— Nathaniel Schutta, arquiteto como serviço, ntschutta.io Mark e Neal se propuseram a alcançar uma meta formidável: elucidar os muitos fundamentos em camadas requeridos para se destacar na arquitetura de software, e eles cumpriram essa missão. O campo da arquitetura de software se desenvolve continuamente e a função requer uma amplitude e profundidade assustadoras de conhecimento e habilidades. Este livro servirá como um guia para muitos em suas jornadas no domínio da arquitetura de software.

— Rebecca J. Parsons, CTO, ThoughtWorks Mark e Neal realmente capturaram as recomendações do mundo real dos especialistas em tecnologia para orientarem a excelência da arquitetura. Eles conseguiram isso identificando as características comuns da arquitetura e as concessões necessárias para gerar o sucesso.

— Cassie Shum, diretora técnica, ThoughtWorks

Página 5

Página 6

Fundamentos da Arquitetura de Soware Copyright © 2024 ALTA BOOKS.

Copyright © 2020 Mark Richards, Neal Ford.

ISBN: 978-85-508-1975-4 Authorized Portuguese translaon of the English edion of Fundamentals of Soware Architecture ISBN 9781492043454 © 2020 Mark Richards, Neal Ford. This translaon is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same. PORTUGUESE language edion published by Grupo Editorial Alta Books Ltda., Copyright © 2024 by STARLIN ALTA EDITORA E CONSULTORIA LTDA.

1ª Edição, 2024 — Edição revisada conforme o Acordo Ortográfico da Língua Portuguesa de 2009.

Dados Internacionais de Catalogação na Publicação (CIP) de acordo com ISBD R514f Richards, Mark Fundamentos da Arquitetura de Soware: Uma abordagem de engenharia / Mark Richards, Neal Ford ; traduzido por Eveline Machado. – Rio de Janeiro : Alta Books, 2024.

ePub3.

Tradução de: Fundamentals of Soware Architecture Inclui apêndice.

ISBN: 978-85-508-1975-4

1. Ciência da computação. 2. Arquitetura de Soware. I. Ford,

Neal. II. Machado, Eveline. III. Título 2024-113 CDD 004 CDU 004 Elaborado por Vagner Rodolfo da Silva – CRB-8/9410 Índice para catálogo sistemáco:

1. 1. Ciência da computação 004
2. 2. Ciência da computação 004

Todos os direitos estão reservados e protegidos por Lei. Nenhuma parte deste livro, sem autorização prévia por escrito da editora, poderá ser reproduzida ou transmida.

A violação dos Direitos Autorais é crime estabelecido na Lei nº 9.610/98 e com punição de acordo com o argo 184 do Código Penal.

O conteúdo desta obra fora formulado exclusivamente pelo(s) autor(es).

Página 7

Marcas Registradas: Todos os termos mencionados e reconhecidos como Marca Registrada e/ou Comercial são de responsabilidade de seus proprietários. A editora informa não estar associada a nenhum produto e/ou fornecedor apresentado no livro.

Material de apoio e erratas: Se parte integrante da obra e/ou por real necessidade, no site da editora o leitor encontrará os materiais de apoio (download), errata e/ou quaisquer outros conteúdos aplicáveis à obra. Acesse o site www.altabooks.com.br e procure pelo tulo do livro desejado para ter acesso ao conteúdo..

Suporte Técnico: A obra é comercializada na forma em que está, sem direito a suporte técnico ou orientação pessoal/exclusiva ao leitor.

A editora não se responsabiliza pela manutenção, atualização e idioma dos sites, programas, materiais complementares ou similares referidos pelos autores nesta obra.

Produção Editorial: Grupo Editorial Alta Books Diretor Editorial: Anderson Vieira Vendas Governamentais: Crisane Mutüs Gerência Comercial: Claudio Lima Gerência Markeng: Andréa Guaello Assistente Editorial: Isabella Gibara Tradução: Eveline Machado Copidesque: Rafael Surgek Revisão: Renan Amorim; André Cavanha Diagramação: Joyce Matos Revisão Técnica: Jhonatan Pereira (Desenvolvedor de Soware) Livro digital: Lucas Camargo Rua Viúva Cláudio, 291 — Bairro Industrial do Jacaré CEP: 20.970-031 — Rio de Janeiro (RJ) Tels.: (21) 3278-8069 / 3278-8419 www.altabooks.com.br — altabooks@altabooks.com.br Ouvidoria: ouvidoria@altabooks.com.br

Página 8

Sumário Prefácio: Invalidando Axiomas

1. Introdução

Definindo Arquitetura de Software Expectativas de um Arquiteto Tomar Decisões de Arquitetura Analisar Continuamente a Arquitetura Manter-se Atualizado com as Últimas Tendências Assegurar a Conformidade com as Decisões Exposição e Experiência Diversificadas Ter Conhecimento sobre o Domínio do Negócio Ter Habilidades Interpessoais Entender e Lidar Bem com Questões Políticas Interseção da Arquitetura e… Práticas da Engenharia Operações/DevOps Processo Dados Leis da Arquitetura de Software Parte I. Fundamentos 2. Pensamento Arquitetônico Arquitetura Versus Design

Página 9

Amplitude Técnica Analisando os Trade-offs Entendendo as Motivações Comerciais Equilibrando Arquitetura e Codificação 3. Modularidade Definição Medindo a Modularidade Coesão Acoplamento Abstração, Instabilidade e Distância da Sequência Principal Distância da Sequência Principal Conascência Unificando as Métricas de Acoplamento e Conascência De Módulos a Componentes 4. Definição das Características da Arquitetura Características da Arquitetura Listadas (em Parte) Características Operacionais da Arquitetura Características Estruturais da Arquitetura Características Transversais da Arquitetura Trade-offs e Arquitetura Menos Pior 5. Identificando as Características da Arquitetura Extraindo Características da Arquitetura das Preocupações do Domínio Extraindo Características da Arquitetura dos Requisitos Estudo de Caso: Silicon Sandwiches Características Explícitas Características Implícitas 6. Medindo e Controlando as Características da Arquitetura Medindo as Características da Arquitetura

Página 10

Medidas Operacionais Medidas Estruturais Medidas do Processo Governança e Funções de Aptidão Governando as Características da Arquitetura Funções de Aptidão 7. Escopo das Características da Arquitetura Acoplamento e Conascência Quanta Arquitetural e Granularidade Estudo de Caso: Going, Going, Gone 8. Pensamento Baseado em Componentes Escopo do Componente Função do Arquiteto Particionamento da Arquitetura Estudo de Caso: Silicon Sandwiches: Particionamento Função do Desenvolvedor Fluxo de Identificação dos Componentes Identificando os Componentes Iniciais Atribuir Requisitos aos Componentes Analisar Funções e Responsabilidades Analisar as Características da Arquitetura Reestruturar os Componentes Granularidade do Componente Design do Componente Descobrindo os Componentes Estudo de Caso: Going, Going, Gone: Descobrindo os Componentes Quantum da Arquitetura Revisitado: Escolhendo Entre Arquiteturas Monolíticas Versus Distribuídas

Página 11

Parte II. Estilos de Arquitetura

9. Fundamentos

Padrões Fundamentais A Grande Bola de Lama Arquitetura Unitária Cliente/Servidor Arquiteturas Monolíticas Versus Distribuídas Falácia 1: A Rede É Confiável Falácia 2: A Latência É Zero Falácia 3: A Largura de Banda É Infinita Falácia 4: A Rede É Segura Falácia 5: A Topologia Nunca Muda Falácia 6: Existe Apenas Um Administrador Falácia 7: O Custo do Transporte É Zero Falácia 8: A Rede É Homogênea Outras Considerações Distribuídas 10. Estilo de Arquitetura em Camadas Topologia Camadas de Isolamento Adicionando Camadas Outras Considerações Por que Usar Esse Estilo de Arquitetura Classificações das Características da Arquitetura 11. Estilo de Arquitetura Pipeline Topologia Canais Filtros Exemplo Classificações das Características da Arquitetura

Página 12

12. Estilo de Arquitetura Microkernel

Topologia Sistema Central Componentes de Plug-in Registro Contratos Exemplos e Casos de Uso Classificações das Características da Arquitetura 13. Estilo de Arquitetura Baseada em Serviços Topologia Variantes da Topologia Design do Serviço e Granularidade Particionamento do Banco de Dados Arquitetura de Exemplo Classificações das Características da Arquitetura Quando Usar Esse Estilo de Arquitetura 14. Estilo de Arquitetura Orientada a Eventos Topologia Topologia do broker Topologia do Mediador Capacidades Assíncronas Tratamento de Erro Evitando a Perda de Dados Capacidades de Transmissão Requisição-Resposta Escolhendo Entre Modelo Baseado em Requisição e Orientado a eventos Arquiteturas Híbridas Orientadas a Eventos Classificações das Características da Arquitetura

Página 13

15. Estilo de Arquitetura Baseada em Espaço

Topologia Geral Unidade de Processamento Middleware Virtualizado Data Pumps Gravações de Dados Leituras de Dados Colisões de Dados Implementações na Nuvem Versus Locais Cache Replicado Versus Distribuído Observações sobre o Near-Cache Exemplos de Implementação Sistema de Ingressos para Concertos Sistema de Leilão Online Classificações das Características da Arquitetura 16. Arquitetura Orientada a Serviços e Baseada em Orquestração História e Filosofia Topologia Taxonomia Serviços do Negócio Serviços Corporativos Serviços do Aplicativo Serviços da Infraestrutura Mecanismo de Orquestração Fluxo das Mensagens Reutilização… e Acoplamento Classificações das Características da Arquitetura 17. Arquitetura de Microsserviços História Topologia

Página 14

Distribuída Contexto Delimitado Granularidade Isolamento dos Dados Camada da API Reutilização Operacional Front-ends Comunicação Coreografia e Orquestração Transações e Sagas Classificações das Características da Arquitetura Referências Adicionais 18. Escolhendo o Estilo de Arquitetura Certo A Mudança de “Moda” na Arquitetura Critérios de Decisão Estudo de Caso Monolítico: Silicon Sandwiches Monolítico Modular Microkernel Estudo de Caso Distribuído: Going, Going, Gone Parte III. Técnicas e Habilidades Sociais 19. Decisões da Arquitetura Antipadrões da Decisão de Arquitetura Antipadrão Cobertura dos Ativos Antipadrão Feitiço do Tempo Antipadrão Arquitetura Baseada em E-mail Significante para a Arquitetura Registros de Decisão da Arquitetura Estrutura Básica Armazenando ADRs

Página 15

ADRs como Documentação Usando ADRs para Padrões Exemplo

20. Analisando o Risco da Arquitetura

Matriz de Risco Avaliações do Risco Risk Storming Identificação Consenso Análise de Risco da História com a Metodologia Ágil Exemplos de Risk Storming Disponibilidade Elasticidade Segurança 21. Diagramando e Apresentando a Arquitetura Diagramando Ferramentas Padrões da Diagramação: UML, C4 e ArchiMate Diretrizes do Diagrama Apresentação Manipulando o Tempo Construções Incrementais Infodecks Versus Apresentações Os Slides São Metade da História Invisibilidade 22. Tornando as Equipes Eficientes Limites da Equipe Personalidades do Arquiteto Controlador

Página 16

Arquiteto Folgado Arquiteto Eficiente Quanto Controle?

Sinais de Aviso da Equipe Utilizando Checklists Checklist da Completude de código do desenvolvedor Checklist dos Testes Unitários e Funcionais Checklist de Release do Software Dando Orientação Resumo 23. Habilidades de Negociação e Liderança Negociação e Facilitação Negociando com os Acionistas da Empresa Negociando com Outros Arquitetos Negociando com os Desenvolvedores Arquiteto de Software como um Líder Os 4 Cs da Arquitetura Seja Pragmático, Mas Visionário Liderando as Equipes Dando o Exemplo Integração com a Equipe de Desenvolvimento Resumo 24. Desenvolvendo uma Trajetória Profissional Regra dos 20 Minutos Desenvolvendo um Radar Pessoal Radar da Tecnologia da ThoughtWorks Partes de Visualização Open Source Usando a Rede Social Conselhos de Despedida Apêndice: Perguntas de Autoavaliação

Página 17

Prefácio: Invalidando Axiomas

Axioma Afirmação ou proposição vista como estabelecida, aceita ou verdade evidente.

Os matemáticos criam teorias com base em axiomas, suposições para coisas verdadeiras e indiscutíveis. Os arquitetos de software também criam teorias sobre axiomas, mas o mundo do software é, bem, mais suave do que a matemática: coisas fundamentais continuam a mudar com rapidez, inclusive os axiomas nos quais baseamos nossas teorias.

O ecossistema de desenvolvimento de software existe em um estado constante de equilíbrio dinâmico: embora exista em um estado equilibrado em determinado momento, ele apresenta um comportamento dinâmico em longo prazo. Um excelente exemplo moderno da natureza desse ecossistema segue a ascensão da conteinerização e das mudanças concomitantes: ferramentas como o Kubernetes não existiam há uma década, mas agora há conferências de software completas para atender seus usuários. O ecossistema de softwares muda de forma caótica: uma pequena mudança causa outra pequena mudança; quando isso se repete centenas de vezes, cria-se um novo ecossistema.

Os arquitetos têm uma responsabilidade importante: questionarem as suposições e os axiomas que sobraram das épocas anteriores. Muitos livros sobre arquitetura de software foram escritos em uma época que mal lembra o mundo atual. De fato, os autores acreditam que devemos questionar os axiomas fundamentais com regularidade, sob a luz de práticas de engenharia aprimoradas, ecossistemas operacionais e processos de desenvolvimento de software, tudo que compõe o

Página 18

equilíbrio confuso e dinâmico em que arquitetos e desenvolvedores trabalham todo dia.

Ao longo do tempo, observadores cuidadosos da arquitetura de software testemunharam uma evolução das capacidades. Iniciando com as práticas de engenharia da Programação Extrema (Extreme Programming), continuando com a Entrega Contínua, a revolução DevOps, os microsserviços, a conteinerização e, agora, os recursos baseados em nuvem, todas essas inovações levaram a novas capacidades e trade-offs. Conforme as capacidades foram mudando, as perspectivas dos arquitetos acompanharam no setor. Por muitos anos, a definição irônica da arquitetura de software era “aquilo que é difícil de mudar depois”. Depois, apareceu o estilo da arquitetura de microsserviços, em que a mudança é um aspecto de design por excelência.

Cada nova era requer novas práticas, ferramentas, medidas, padrões e muitas outras mudanças. Este livro examina a arquitetura de software sob uma luz moderna, considerando todas as inovações da última década, junto a algumas métricas novas e medidas adequadas às novas estruturas e perspectivas de hoje.

O subtítulo do nosso livro é “Uma abordagem de engenharia”. Há tempos os desenvolvedores queriam mudar o desenvolvimento de software de um ofício, em que artesãos habilidosos podem criar trabalhos únicos, para uma disciplina de engenharia, que implica uma análise de repetição, rigor e eficiência. Embora a engenharia de software ainda fique atrás de outros tipos de disciplinas de engenharia em muitas ordens de grandeza (para ser justo, software é uma disciplina muito jovem comparada com outros tipos de engenharia), os arquitetos fizeram grandes melhorias, que serão examinadas nesta obra. Em particular, as práticas modernas de engenharia ágil permitiram um grande progresso nos sistemas que os arquitetos projetam.

Também vemos a questão da análise de trade-off, com uma importância crítica. Como desenvolvedor de software, é fácil se apaixonar por uma tecnologia ou uma abordagem em particular. Mas

Página 19

Página 20

Fonte monoespaçada em itálico Mostra o texto que deve ser substituído pelos valores fornecidos pelo usuário ou valores determinados pelo contexto.

Este elemento significa dica ou sugestão.

Usando Exemplos de Código O material complementar (exemplos de código, exercícios etc.) está disponível para download em http://fundamentalsofsoftwarearchitecture.com (conteúdo em inglês).

Este livro existe para ajudá-lo a fazer seu trabalho. Em geral, se o código de exemplo for oferecido com o livro, talvez você o use em seus programas e documentação. Não é preciso entrar em contato e pedir permissão, a menos que esteja reproduzindo uma grande parte do código. Por exemplo, escrever um programa que usa várias partes de código deste livro não requer permissão. Vender ou distribuir exemplos dos livros da Alta Books requer permissão. Responder a uma pergunta citando este livro ou o código de exemplo não requer permissão. Incorporar uma grande quantidade do código de exemplo deste livro na documentação do seu produto, sim.

Agradecemos, mas não exigimos que você use citações ou referências.

Uma referência geralmente inclui o autor, o título, o editor e a data de publicação. Por exemplo “Richards, Mark; Ford, Neal. Fundamentos da Arquitetura de Software, Rio de Janeiro: Alta Books, 2024”.

Se você acha que seu uso dos exemplos de código excede a utilização justa ou a permissão dada acima, entre em contato em permissions@oreilly.com (conteúdo em inglês).

Página 21

Agradecimentos Mark e Neal gostariam de agradecer a todos que participaram das aulas, dos workshops, das conferências, das reuniões de grupos de usuários, assim como a todos que viram as versões deste material e deram um feedback valioso. Também gostaríamos de agradecer à equipe editorial, que tornou a experiência de escrever um livro a menos problemática possível. Gostaríamos de agradecer a Jay Zimmerman, diretor da “No Stuff Just Fluff”, por criar uma série de conferências que permite o crescimento e a divulgação de um bom conteúdo técnico, e a todos os outros palestrantes cujo feedback e ombros amigos apreciamos. Também agradecemos a alguns oásis aleatórios de sanidade mental e grupos de ideias, com nomes do tipo Pasty Geeks e Hacker B&B.

Agradecimentos de Mark Richards Além dos agradecimentos anteriores, gostaria de agradecer à minha adorável esposa, Rebecca. Assumindo tudo em casa e sacrificando a oportunidade de trabalhar em seu próprio livro, ela me permitiu fazer serviços de consultoria extras, falar em mais conferências e cursos de treinamento, tendo a oportunidade de praticar e aprimorar o material deste livro. Você é a melhor.

Agradecimentos de Neal Ford Neal gostaria de agradecer à sua família estendida, a ThoughtWorks, coletivamente, e a Rebecca Parsons e Marting Fowler de forma individual. A ThoughtWorks é um grupo extraordinário que consegue produzir valor para clientes mantendo um olho aguçado sobre como as coisas funcionam de modo que possamos melhorá-las, e deu suporte para este livro de inúmeros modos e continua a desenvolver funcionários que desafiam e inspiram todo dia. Neal gostaria também de agradecer ao barzinho do bairro pelas escapadas regulares na rotina. Enfim, Neal agradece à sua esposa, Candy, cuja tolerância pela

Página 22

escrita do livro e pelas conferências aparentemente não tem limites.

Por décadas ela me mantém com os pés no chão e com sanidade suficiente para funcionar, e espero que seja assim por outras décadas, sendo o amor da minha vida.

Página 23

1. Introdução

CAPÍTULO 1 Introdução A função de “arquiteto de software” aparece no topo de várias listas das melhores profissões no mundo. No entanto, quando os leitores veem outras profissões nessas listas (como profissional de enfermagem ou gerente financeiro), há uma trajetória profissional clara para eles. Por que não existe uma trajetória para os arquitetos de software?

Primeiro, o setor não tem uma boa definição própria para arquitetura de software. Quando damos aulas de nível básico, os alunos costumam pedir uma definição concisa do que faz um arquiteto de software e nos recusamos categoricamente a fazer isso, e não somos os únicos. No famoso documento técnico “Who Needs an Architect?”, Martin Fowler ficou conhecido por se recusar a definir a função, remetendo à famosa citação:

Arquitetura é sobre algo importante… seja lá o que for.

— Ralph Johnson Quando pressionados, criamos o mapa mental mostrado na Figura 1-1, que lamentavelmente está incompleto, mas é um indicativo do escopo da arquitetura de software. De fato, daremos nossa definição concisa de arquitetura de software.

Segundo, como o mapa mental mostra, a função do arquiteto de software incorpora uma enorme quantidade e domínio de responsabilidade que continua a se expandir. Há uma década, os arquitetos de software lidavam apenas com os aspectos puramente técnicos da arquitetura, como modularidade, componentes e padrões. Desde então, devido aos novos estilos de arquitetura que aproveitam uma faixa maior de capacidades (como microsserviços), a função do arquiteto de software foi ampliada. Cobrimos as diversas interseções da arquitetura e do resto da organização na seção “Interseção da Arquitetura e…”.

Página 24

Figura 1-1. As responsabilidades de um arquiteto de software incluem habilidades técnicas, sociais, consciência operacional muitas outras Terceiro, o arquiteto de software é um alvo sempre móvel por causa da evolução rápida do ecossistema de desenvolvimento de software. Qualquer definição dada hoje ficará irremediavelmente desatualizada em poucos anos. A definição na Wikipédia de arquitetura de software fornece uma visão geral razoável, mas muitas afirmações estão desatualizadas, como “Arquitetura de software significa fazer escolhas estruturais fundamentais cuja mudança custa caro após a implementação”. Todavia, os arquitetos projetaram estilos arquiteturais modernos, como microsserviços, com a ideia de desenvolvimento incremental; mudanças estruturais nos microsserviços agora não custam caro. Claro, essa capacidade implica decisões difíceis envolvendo preocupações, como o acoplamento. Muitos livros sobre arquitetura de software a tratam como um problema estático; assim que resolvida, pode ser tranquilamente ignorada.

Porém, neste livro reconhecemos a natureza dinâmica inerente da arquitetura de software, inclusive a definição em si.

Quarto, grande parte do material sobre arquitetura de software tem apenas relevância histórica.

Os leitores da página da Wikipédia não deixarão de notar o conjunto desconcertante de siglas e referências cruzadas para um universo inteiro de conhecimento. Contudo, muitas dessas siglas representam tentativas desatualizadas ou fracassadas. Até as soluções que eram perfeitamente válidas poucos anos atrás podem não funcionar agora porque o contexto mudou. A história da arquitetura de software está repleta de coisas que os arquitetos tentaram e perceberam os efeitos colaterais prejudiciais. Tratamos de muitas dessas lições neste livro.

Atualmente, por que escrever um livro sobre os fundamentos da arquitetura de software? O escopo dessa arquitetura não é a única parte do mundo de desenvolvimento que muda constantemente. Novas tecnologias, técnicas, capacidades… na verdade, é mais fácil achar coisas que não mudaram na última década do que listar todas as mudanças. Os arquitetos de software devem tomar decisões dentro desse ecossistema em constante mudança. Como tudo muda, inclusive os fundamentos sobre os quais tomamos decisões, os arquitetos devem reexaminar alguns axiomas centrais que embasaram os primeiros textos sobre arquitetura de

Página 25

software. Por exemplo, os primeiros livros sobre essa arquitetura não levam em conta o impacto do DevOps porque ele não existia quando foram escritos.

Ao estudar arquitetura, os leitores devem ter em mente que, como nas artes, ela só pode ser compreendida no contexto. Muitas decisões que os arquitetos tomaram foram baseadas nas realidades do ambiente em que se encontravam. Por exemplo, um dos maiores objetivos da arquitetura no final do século XX incluía fazer o uso mais eficiente dos recursos compartilhados, pois toda a infraestrutura na época era cara e comercial: sistemas operacionais, servidores de aplicações, servidores de bancos de dados etc. Imagine passar por um datacenter de 2002 e dizer para o chefe de operações: “Oi, tenho uma ótima ideia para um estilo revolucionário de arquitetura: cada serviço acontece em seu próprio maquinário isolado, com seu próprio banco de dados dedicado (descrevendo o que agora conhecemos como microsserviços). Então, isso significa que precisarei de cinquenta licenças para o Windows, outras trinta licenças para os servidores de aplicação e, pelo menos, cinquenta licenças para os servidores de banco de dados.” Em 2002, tentar construir uma arquitetura como microsserviços teria um custo impeditivo. Todavia, com o advento do open source nos anos seguintes, junto às práticas de engenharia atualizadas via revolução DevOps, foi possível construir uma arquitetura como a descrita. Os leitores devem lembrar que todas as arquiteturas são um produto de seu contexto.

Definindo Arquitetura de Software

O setor inteiro se esforçou para definir “arquitetura de software” com precisão. Alguns arquitetos se referem a ela como o blueprint do sistema, já outros a definem como roadmap para desenvolver um sistema. O problema com essas definições comuns é entender o que há de fato em um blueprint ou em um roadmap. Por exemplo, o que é verificado quando um arquiteto analisa uma arquitetura?

A Figura 1-2 mostra um modo de pensar a arquitetura de software. Nessa definição, a arquitetura consiste na estrutura do sistema (as linhas pretas grossas que dão suporte à arquitetura), combinada com as características da arquitetura (“atributos”) que o sistema deve alicerçar, as decisões da arquitetura, e por fim, os princípios de design.

Página 26

Figura 1-2. Arquitetura consiste na estrutura combinada com as características da arquitetura (atributos), as decisões da arquitetura e os princípios do design A estrutura do sistema, como mostrada na Figura 1-3, se refere ao estilo (ou estilos) de arquitetura no qual o sistema está sendo implementado (como microsserviços, camadas ou microkernel). Descrever uma arquitetura unicamente pela estrutura não exibe essa arquitetura em sua totalidade. Por exemplo, suponha que se peça a um arquiteto para que descreva uma arquitetura, e ele responde: “É uma arquitetura de microsserviços.” Nesse caso, o arquiteto fala apenas da estrutura do sistema, não da arquitetura do sistema. O conhecimento das características da arquitetura, das decisões da arquitetura e dos princípios do design também é necessário para entender bem a arquitetura do sistema.

Página 27

Figura 1-3. Estrutura se refere aos estilos de arquitetura usados no sistema As características da arquitetura são outra dimensão da definição da arquitetura de software (veja a Figura 1-4). As características definem os critérios de sucesso de um sistema, em geral ortogonal quanto à funcionalidade. Note que todas as características listadas não requerem conhecimento da funcionalidade do sistema, embora sejam necessárias para ele funcionar corretamente. Essas características são tão importantes que dedicamos vários capítulos neste livro para entendê-las e defini-las.

Figura 1-4. As características se referem aos “atributos” que o sistema deve suportar

Página 28

O próximo fator que define a arquitetura de software são as decisões da arquitetura. Essas decisões definem as regras de como um sistema deve ser construído. Por exemplo, um arquiteto pode tomar uma decisão de arquitetura em que apenas as camadas comerciais e de serviços em uma arquitetura em camadas possam acessar o banco de dados (veja a Figura 1-5), impedindo a camada de apresentação de fazer chamados diretos no banco de dados. As decisões da arquitetura formam os limites do sistema e orientam as equipes de desenvolvimento sobre o que é ou não permitido.

Figura 1-5. Decisões da arquitetura são regras para construir sistemas Se certa decisão da arquitetura não pode ser implementada em uma parte do sistema devido a alguma condição ou outra restrição, essa decisão (ou regra) pode ser derrubada com algo chamado variância. A maioria das organizações tem modelos de variância usados por um Conselho de Revisão de Arquitetura (ARB — sigla em inglês para Architecture Review Board) ou pelo arquiteto-chefe. Esses modelos formalizam o processo de buscar uma variância para certo padrão ou decisão de arquitetura. Uma exceção para determinada decisão de arquitetura é analisada pelo ARB (ou arquiteto-chefe se não existe um ARB), sendo aprovada ou negada com base em justificativas e concessões.

O último fator na definição de arquitetura são os princípios do design. Tal princípio difere de uma decisão da arquitetura no sentido de que um princípio do design é uma diretriz, não uma regra rígida. Por exemplo, o princípio do design mostrado na Figura 1-6 estabelece que as equipes de desenvolvimento devem utilizar a mensageria assíncrona entre os serviços em uma arquitetura de microsserviços para aumentar o desempenho. Uma decisão (regra) da arquitetura nunca consegue abranger todas as condições e opções para a comunicação entre os serviços, portanto um princípio do design pode ser usado para orientar o método preferido (nesse caso, a mensageria assíncrona) e permitir que o desenvolvedor escolha um protocolo de comunicação mais adequado (como REST ou gRPC), dada uma circunstância específica.

Página 29

Expectativas de um Arquiteto

Figura 1-6. Princípios do design são diretrizes para construir sistemas Expectativas de um Arquiteto Definir o papel de um arquiteto de software se mostra tão difícil quanto definir a arquitetura de software. Pode variar desde um programador especializado até definir a direção técnica estratégica para a empresa. Em vez de perder tempo com a busca inútil de definir a função, recomendamos focar as expectativas de um arquiteto.

Existem oito expectativas principais para um arquiteto de software, independentemente de qualquer função, cargo ou descrição do trabalho:

Tomar Decisões de Arquitetura

Analisar continuamente a arquitetura Manter-se atualizado com as últimas tendências Assegurar a conformidade com as decisões Exposição e experiência diversificadas Ter conhecimento sobre o domínio do negócio Ter habilidades interpessoais Entender e lidar bem com questões políticas O primeiro segredo para a eficiência e o sucesso na função de arquiteto de software depende de compreender e praticar cada uma dessas expectativas.

Tomar Decisões de Arquitetura Um arquiteto deve estabelecer as decisões da arquitetura e os princípios do design usados para orientar as decisões de tecnologia dentro da equipe, do departamento ou em toda a empresa.

Página 30

Orientação é a palavra de ordem nessa primeira expectativa. Um arquiteto deve orientar, não especificar as escolhas da tecnologia. Por exemplo, um arquiteto pode tomar a decisão de usar React.js para um desenvolvimento front-end. Nesse caso, ele está tomando uma decisão técnica, não uma decisão arquitetural ou um princípio do design que ajudará a equipe de desenvolvimento a fazer escolhas. Um arquiteto deve instruir as equipes de desenvolvimento para usarem um framework reativo para o desenvolvimento web front-end, orientando a equipe ao fazer a escolha entre Angular, Elm, React.js, Vue ou qualquer outro framework web reativo.

É difícil orientar as escolhas da tecnologia com decisões da arquitetura e princípios do design.

O segredo para tomar decisões arquiteturais eficientes é perguntar se a decisão da arquitetura está ajudando a orientar as equipes ao fazerem a escolha técnica certa ou se a decisão faz a escolha técnica por elas. Dito isso, por vezes um arquiteto talvez precise tomar decisões de tecnologia específicas para preservar uma característica da arquitetura em particular, como escalabilidade, desempenho ou disponibilidade. Nesse caso, ainda seria considerada uma decisão de arquitetura, mesmo que especifique uma tecnologia em particular. Em geral, os arquitetos se esforçam para encontrar a linha certa, portanto o Capítulo 19 é totalmente sobre decisões da arquitetura.

Analisar Continuamente a Arquitetura

Um arquiteto deve analisar continuamente a arquitetura e o ambiente de tecnologia atual, para então recomendar soluções de melhorias.

Essa expectativa de um arquiteto se refere à vitalidade da arquitetura, que avalia se uma arquitetura é viável hoje tendo sido definida há três anos ou mais, dadas as mudanças no negócio e na tecnologia. Conforme nossa experiência, poucos arquitetos focam suas energias em analisar continuamente as arquiteturas existentes. Como resultado, a maioria deles enfrenta elementos de decadência estrutural, o que ocorre quando os desenvolvedores fazem mudanças no código ou no design que impactam as características arquiteturais requeridas, como desempenho, disponibilidade e escalabilidade.

Outros aspectos esquecidos dessa expectativa que os arquitetos costumam negligenciar são os ambientes de teste e lançamento. A agilidade na modificação do código tem benefícios óbvios, mas se as equipes precisam de semanas para testar as mudanças e meses para lançar, então os arquitetos não conseguem ter agilidade na arquitetura em geral.

Um arquiteto deve analisar integralmente as mudanças na tecnologia e os domínios do problema para determinar a robustez da arquitetura. Embora essa consideração apareça raramente em um anúncio de empregos, os arquitetos devem atender a essa expectativa para manter os aplicações relevantes.

Manter-se Atualizado com as Últimas Tendências

Um arquiteto deve ficar atualizado com as últimas tendências da tecnologia e do setor.

Os desenvolvedores devem ficar atualizados com as últimas tecnologias usadas diariamente para manterem a si mesmos (e seu trabalho!) relevantes. Um arquiteto tem um requisito ainda mais crítico de se manter atual com as últimas tendências técnicas e do setor. As decisões que um arquiteto toma tendem a ser de longo prazo e difíceis de mudar. Entender e seguir as principais tendências contribui para que ele se prepare para o futuro e tome a decisão certa.

Página 31

Seguir as tendências e se manter atualizado com elas é difícil, sobretudo para um arquiteto de software. No Capítulo 24, examinaremos as várias técnicas e recursos sobre como fazer isso.

Assegurar a Conformidade com as Decisões

Um arquiteto deve assegurar a conformidade com as decisões de arquitetura e os princípios de design.

Assegurar a conformidade significa que o arquiteto verifica continuamente se as equipes de desenvolvimento seguem as decisões da arquitetura e os princípios do design definidos, documentados e comunicados por ele. Considere o cenário em que um arquiteto toma a decisão de restringir o acesso ao banco de dados em uma arquitetura de camadas apenas para as camadas de negócio e serviços (e não para camada de apresentação). Isso significa que a camada de apresentação deverá passar por todas as camadas da arquitetura para fazer até o mais simples chamado do banco de dados. Um desenvolvedor da interface do usuário poderá discordar dessa decisão e acessar o banco de dados (ou a camada de persistência) diretamente por motivos de desempenho. Contudo, o arquiteto tomou essa decisão de arquitetura por um motivo específico: controlar as mudanças. Fechando as camadas, as mudanças no banco de dados podem ser feitas sem impactar a camada de apresentação. Por não assegurar a conformidade com as decisões da arquitetura, esse tipo de violação pode acontecer, a arquitetura não atenderá às características requeridas (atributos) e a aplicação ou o sistema não funcionará como esperado.

No Capítulo 6, veremos mais sobre como medir a conformidade usando funções de adequação e ferramentas automatizadas.

Exposição e Experiência Diversificadas

Um arquiteto deve se expor a tecnologias, estruturas, plataformas e ambientes múltiplos e diversificados.

Essa expectativa não significa que um arquiteto deve ser especialista em toda estrutura, plataforma e linguagem, mas deve estar familiarizado pelo menos com várias tecnologias. A maioria dos ambientes atuais é heterogênea e, no mínimo, um arquiteto deve saber como se comunicar com vários sistemas e serviços, não importando a linguagem, a plataforma e a tecnologia nas quais esses sistemas ou serviços estão escritos.

Um dos melhores modos de dominar essa expectativa é o arquiteto aumentar sua zona de conforto. Focar apenas uma tecnologia ou plataforma é um porto seguro. Um arquiteto de software eficiente deve ser agressivo ao buscar oportunidades para ter experiência em várias linguagens, plataformas e tecnologias. Uma boa maneira de dominar a expectativa é se concentrar na amplitude técnica, não na profundidade técnica. Amplitude técnica inclui o que você sabe, mas não com detalhes, combinado com o que você sabe muito. Por exemplo, é muito melhor que o arquiteto esteja familiarizado com dez produtos de cache diferentes e com os prós e contras associados a cada um do que ser especialista em apenas um deles.

Ter Conhecimento sobre o Domínio do Negócio

Um arquiteto deve ter certo nível de especialização no domínio do negócio.

Página 32

Os arquitetos de software eficientes entendem não apenas de tecnologia, mas do domínio do negócio no espaço do problema. Sem conhecimento do domínio do negócio, fica difícil entender o problema comercial, as metas e os requisitos, complicando planejar uma arquitetura eficiente para atender aos requisitos da empresa. Imagine ser arquiteto em uma grande instituição financeira e não entender os termos financeiros comuns, como índice direcional médio, contratos aleatórios, aumento das taxas ou mesmo dívida não prioritária. Sem esse conhecimento, um arquiteto não consegue se comunicar com os stakeholders e com os usuários do negócio, perdendo rápido a credibilidade.

Os arquitetos mais bem-sucedidos que conhecemos são aqueles com conhecimento técnico amplo e prático, além de um bom conhecimento de certo domínio. Tais arquitetos de software conseguem se comunicar bem com os executivos da diretoria e com os usuários comerciais, usando o conhecimento do domínio e uma linguagem que stakeholders conhecem e entendem.

Isso acaba gerando uma grande confiança de que o arquiteto de software sabe o que está fazendo e tem competência para criar uma arquitetura eficiente e correta.

Ter Habilidades Interpessoais

Um arquiteto deve ter habilidades interpessoais excepcionais, inclusive trabalho em equipe, facilitação e liderança.

Ter habilidades excepcionais de liderança e interpessoais é uma expectativa difícil para a maioria dos desenvolvedores e dos arquitetos. Como técnicos, os desenvolvedores e arquitetos gostam de resolver problemas técnicos, não problemas com pessoas. Contudo, segundo a famosa frase de Gerald Weinberg: “Não importa o que dizem, sempre é um problema com pessoas.” Um arquiteto não deve apenas dar uma orientação técnica para a equipe, mas também liderar as equipes de desenvolvimento na implementação da arquitetura. As habilidades de liderança são, pelo menos, metade do que é preciso para se tornar um arquiteto de software eficiente, não importa a função ou o cargo dele.

O setor está repleto de arquitetos de software, todos competindo por um número limitado de posições na arquitetura. Ter grandes habilidades de liderança e interpessoais é uma boa maneira de um arquiteto se diferenciar dos outros, de se destacar na multidão. Conhecemos muitos arquitetos de software que são excelentes técnicos, mas arquitetos ineficientes devido à incapacidade de liderar equipes, treinar e aconselhar desenvolvedores e de comunicar com eficiência ideias, decisões e princípios da arquitetura. Nem é preciso dizer que tais arquitetos têm dificuldades de manter uma posição ou um trabalho.

Entender e Lidar Bem com Questões Políticas

Um arquiteto deve entender o clima político da empresa e conseguir lidar bem com ele.

Pode parecer bem estranho falar sobre negociação e lidar com política corporativa em um livro sobre arquitetura de software. Para mostrar como as habilidades de negociação são importantes e necessárias, considere o cenário em que um desenvolvedor toma a decisão de utilizar uma estratégia padrão para reduzir a complexidade ciclomática geral de certa parte de um código complexo. Quem se importa com isso? Uma pessoa pode aplaudir o desenvolvedor por usar tal padrão, mas em quase todos os casos o desenvolvedor não precisa buscar aprovação para tal decisão.

Página 33

Agora considere o cenário em que um arquiteto, responsável por um grande sistema de gerenciamento das relações com o cliente, tem problemas para controlar o acesso ao banco de dados a partir de outros sistemas, assegurar certos dados do cliente e fazer qualquer mudança no esquema do banco de dados porque muitos outros sistemas estão usando o banco de dados CRM. Assim, o arquiteto toma a decisão de criar o que é chamado de silos de aplicação, em que cada banco de dados da aplicação é acessível apenas a partir da aplicação que possui esse banco de dados. Tomar essa decisão dará ao arquiteto mais segurança e controle sobre os dados do cliente e sobre as mudanças. Porém, diferentemente do cenário do desenvolvedor anterior, essa decisão também será questionada por quase todos na empresa (com a possível exceção da equipe de aplicação CRM, claro). Outras aplicações precisam dos dados de gerenciamento de clientes. Se essas aplicações não conseguem mais acessar diretamente o banco de dados, agora devem pedir ao sistema CRM para obter os dados, requerendo chamadas de acesso remotas via REST, SOAP ou algum outro protocolo de acesso remoto.

O ponto principal é que quase toda decisão que um arquiteto toma será questionada. As decisões da arquitetura serão questionadas pelos proprietários do produto, pelos gerentes do projeto e pelos acionistas da empresa devido ao aumento de custos ou esforço (tempo) envolvido. Essas decisões também serão questionadas por desenvolvedores que sentem que a abordagem deles é melhor. Em qualquer caso, o arquiteto deve se envolver na política da empresa e aplicar habilidades básicas de negociação para ter a maioria das decisões aprovada.

Isso pode ser muito frustrante para um arquiteto de software, pois grande parte das decisões tomadas como desenvolvedor não requeria aprovação nem análise. Os aspectos da programação, como estrutura do código, design de classes, escolha do padrão de projeto e, por vezes, até a escolha da linguagem, fazem parte da arte de programar. Porém, um arquiteto, agora finalmente capaz de conseguir tomar decisões amplas e importantes, deve justificar e lutar por quase cada uma dessas decisões. Habilidades de negociação, como as de liderança, são tão essenciais e necessárias que dedicamos um capítulo inteiro no livro para entendê-las (veja o Capítulo 23).

Interseção da Arquitetura e…

O escopo da arquitetura de software aumentou na última década para incluir cada vez mais responsabilidade e perspectiva. Há uma década, a relação típica entre arquitetura e operações era contratual e formal, com muita burocracia. A maioria das empresas, tentando evitar a complexidade de hospedar suas próprias operações, muitas vezes as terceirizava, com obrigações contratuais para acordos de serviços, como tempo de atividade, escala, responsividade e muitas outras características importantes da arquitetura. Agora, as arquiteturas como microsserviços utilizam livremente preocupações exclusivamente operacionais antes. Por exemplo, a escala elástica antes era complicada de incorporar nas arquiteturas (veja o Capítulo 15), enquanto os microsserviços lidavam com menos problemas via ligação entre arquitetos e DevOps.

Página 34

História: Pets.com e Por que Temos uma Escala Elástica A história do desenvolvimento de software tem lições enriquecedoras, boas e ruins. Pressupomos que as capacidades atuais (como a escala elástica) só apareceram um dia por causa de algum desenvolvedor inteligente, mas essas ideias normalmente nascem com lições difíceis. A Pets.com representa um primeiro exemplo de lições difíceis aprendidas. Ela apareceu no início da internet, esperando se tornar a Amazon.com de artigos para pets. Por sorte, ela tinha um departamento de marketing brilhante, que inventou um mascote interessante: um boneco de meia com microfone dizendo coisas irreverentes. Ele se tornou um superstar, aparecendo em público nos desfiles e nos eventos esportivos nacionais.

Infelizmente a gestão da Pets.com aparentemente gastou muito dinheiro com o mascote, não com a infraestrutura.

Quando os pedidos começaram a entrar, o pessoal não estava preparado. O site era lento, as transações se perdiam, as entregas atrasavam etc. … obviamente, o pior cenário possível. Na verdade, foi tão ruim que a empresa logo fechou após uma correria de Natal desastrosa, vendendo apenas o único ativo valioso que restou (o mascote) para um concorrente.

Do que a empresa precisava era de uma escala elástica: a capacidade de gerar mais instâncias de recursos, quando necessário. Os provedores de nuvem oferecem esse recurso como uma commodity, mas, no início da internet, as empresas tinham que gerenciar sua própria infraestrutura e muitos foram vítimas de um fenômeno nunca ouvido antes:

sucesso demais pode acabar com o negócio. A Pets.com e outras histórias terríveis parecidas levaram os engenheiros a desenvolver as estruturas das quais os arquitetos desfrutam atualmente.

As próximas seções detalham as interseções mais recentes entre a função do arquiteto e as outras partes de uma organização, destacando as novas capacidades e as responsabilidades deles.

Práticas da Engenharia

Por tradição, a arquitetura de software foi separada do processo de desenvolvimento usado para criar o software. Dezenas de metodologias populares existem para criar um software, inclusive a Waterfall e muitos tipos de metodologia ágil (como Scrum, Programação Extrema, Lean e Crystal), que não impactam muito a arquitetura de software.

Contudo, nos últimos anos, os avanços da engenharia têm impulsionado as preocupações do processo na arquitetura de software. É bom separar o processo de desenvolvimento de software das práticas de engenharia. Com processo, referimo-nos a como as equipes são formadas e gerenciadas, como as reuniões são feitas e o fluxo de trabalho da organização; isso se refere à mecânica de como as pessoas se organizam e interagem. Já as práticas de engenharia de software se referem às práticas independentes do processo que têm um benefício ilustrado e repetido. Por exemplo, a integração contínua é uma prática de engenharia comprovada que não conta com um processo em particular.

Página 35

O Caminho da Programação Extrema até a Entrega Contínua As origens da Programação Extrema (XP) mostram bem a diferença entre processo e engenharia. No início dos anos 1990, um grupo de desenvolvedores de software experientes, liderado por Kent Beck, começou a questionar dezenas de diferentes processos de desenvolvimento populares na época. Segundo a experiência deles, parecia que nenhum deles tinha criado bons resultados repetidamente. Um dos fundadores da XP dizia que escolher um dos processos existentes “era tão garantido para o sucesso do projeto quanto jogar uma moeda”. Eles decidiram repensar como criar um software e iniciaram o projeto XP em março de 1996. Para fundamentar o processo, eles rejeitaram a sabedoria convencional e focaram as práticas que levaram ao sucesso do projeto no passado, mas ao extremo. O raciocínio era que eles viam uma correlação nos projetos anteriores entre mais testes e maior qualidade. Assim, a abordagem XP para testar foi praticada ao extremo: fazer o desenvolvimento do teste primeiro, assegurando que todo o código fosse testado antes de entrar na base de código.

A XP se concentrou em outros processos ágeis populares que compartilhavam perspectivas semelhantes, mas era uma das poucas metodologias que incluíam práticas de engenharia, como automação, teste, integração contínua e outras técnicas concretas baseadas na experiência. Os esforços para continuar avançando o lado de engenharia do desenvolvimento do software continuaram com o livro Continuous Delivery (sem publicação no Brasil), uma versão atualizada de muitas práticas XP, e deram frutos no movimento DevOps. Em muitos pontos, a revolução DevOps ocorreu quando os profissionais de operações adotaram as práticas de engenharia originalmente defendidas pela XP:

automação, teste, uma fonte de verdade declarada e outras.

Damos muito suporte a esses avanços, que formam as etapas de incremento que acabarão por formar a graduação do desenvolvimento de software como uma disciplina de engenharia adequada.

É importante focar as práticas de engenharia. Primeiro, o desenvolvimento de software não tem muitos recursos das disciplinas de engenharia mais maduras. Por exemplo, os engenheiros civis conseguem prever uma mudança estrutural com muito mais precisão do que os aspectos igualmente importantes da estrutura do software. Segundo, um dos calcanhares de Aquiles do desenvolvimento de software é a estimativa, ou seja: quanto tempo, quantos recursos, quanto dinheiro? Parte dessa dificuldade reside nas práticas de contabilidade antiquadas que não conseguem incluir a natureza exploratória desse desenvolvimento, mas outra parte é porque somos ruins com estimativas por tradição, pelo menos por causa das incógnitas desconhecidas.

… como sabemos, existem conhecimentos conhecidos; existem coisas que sabemos que sabemos. Também sabemos que existem incógnitas conhecidas, ou seja, sabemos que existem coisas que não sabemos. Mas também existem as incógnitas desconhecidas, aquelas que não sabemos que não sabemos.

— Ex-secretário de Defesa dos EUA, Donald Rumsfeld As incógnitas desconhecidas são o inimigo dos sistemas de software. Muitos projetos começam com uma lista de incógnitas conhecidas: coisas que os desenvolvedores devem aprender sobre o domínio e a tecnologia que eles sabem que virão. Porém os projetos também são vítimas das incógnitas desconhecidas: coisas que ninguém sabia que apareceriam, embora tenham aparecido inesperadamente. Por isso os esforços de software do tipo “Grande Design no Início” sofrem:

os arquitetos não conseguem se planejar para as incógnitas desconhecidas. Para citar Mark (um de seus autores):

Todas as arquiteturas se tornam iterativas por causa das incógnitas desconhecidas. A metodologia ágil apenas reconhece isso e age mais cedo.

Assim, embora o processo seja, em grande parte, separado da arquitetura, um processo iterativo fica melhor na natureza da arquitetura de software. As equipes que tentam criar um sistema moderno, como microsserviços, usando um processo antiquado, como Waterfall, terão muito atrito com um processo antiquado que ignora a realidade de como o software é montado.

Página 36

Em geral, o arquiteto também é o responsável técnico nos projetos, portanto determina as práticas de engenharia que a equipe usa. Assim como os arquitetos devem considerar com cuidado o domínio do problema antes de escolher uma arquitetura, eles também devem assegurar que o estilo da arquitetura e as práticas de engenharia formem uma malha simbiótica.

Por exemplo, uma arquitetura de microsserviços pressupõe um provisionamento automatizado de máquinas, teste e implementação automáticos e muitas outras suposições. Tentar criar uma dessas arquiteturas com um grupo de profissionais de operações antiquado, processos manuais e pouco teste gera um atrito enorme e desafios para o sucesso. Como os diferentes domínios do problema se prestam a certos estilos de arquitetura, as práticas de engenharia têm o mesmo tipo de relação simbiótica.

A evolução do pensamento de Programação Extrema para Entrega Contínua segue. Os avanços recentes nas práticas de engenharia permitem novas capacidades na arquitetura. O livro mais recente de Neal, Building Evolutionary Architecture (sem publicação no Brasil), destaca novos modos de pensar a interseção das práticas de engenharia e arquitetura, permitindo uma melhor automação da governança da arquitetura. Embora o livro não seja resumido aqui, ele fornece uma importante nomenclatura nova e um modo de pensar sobre as características da arquitetura que impregnarão grande parte do resto deste livro. O livro de Neal apresenta técnicas para criar arquiteturas que mudam com elegância ao longo do tempo. No Capítulo 4, descrevemos a arquitetura como a combinação de requisitos e preocupações adicionais, como mostrado na Figura 1-7.

Figura 1-7. A arquitetura para um sistema de software consiste em requisitos e em todas as outras características da arquite Como mostra qualquer experiência no mundo do desenvolvimento de software, nada permanece estático. Assim, os arquitetos podem planejar um sistema para atender certos critérios, mas esse design deve sobreviver à implementação (como os arquitetos conseguem assegurar que o design seja implementado corretamente) e à mudança inevitável orientada pelo ecossistema de desenvolvimento de software. Do que precisamos é de uma arquitetura evolutiva.

O livro Building Evolutionary Architecture introduz o conceito de usar funções de adequação para proteger (e gerir) as características da arquitetura conforme ocorre uma mudança ao longo do tempo. O conceito vem da computação evolutiva. Ao planejar um algoritmo genético, os desenvolvedores têm várias técnicas para modificar a solução, desenvolvendo novas soluções de modo iterativo. Ao planejar tal algoritmo para um objetivo específico, os desenvolvedores devem medir o resultado para ver se ele está mais próximo ou distante de uma solução ideal; essa medida é uma função de adequação. Por exemplo, se os desenvolvedores projetaram um algoritmo genético para resolver o problema do caixeiro-viajante (cujo objetivo é a menor rota entre várias cidades), a função de adequação analisaria o caminho percorrido.

O livro Building Evolutionary Architecture reforça a ideia de criar funções de adequação arquiteturais: uma avaliação objetiva da integridade de algumas características da arquitetura.

Essa avaliação pode incluir diversos mecanismos, como métrica, testes unitários, monitores e engenharia do caos. Por exemplo, um arquiteto pode identificar o tempo de carregamento da