A “arquitetura evolutiva de software” é uma contradição?

No meu entendimento, a arquitetura evolutiva se resume a facilitar a modificação da arquitetura. Agora, a arquitetura é frequentemente definida como as coisas que você deve corrigir logo no início, porque será difícil mudar mais tarde.

Como isso se encaixa? Existe alguma diferença entre arquitetura evolutiva e simplesmente minimizar a quantidade de arquitetura?

— Frank Puffer
fonte

"a arquitetura é frequentemente definida como as coisas que você deve corrigir logo no início, porque será difícil mudar mais tarde." A menos que você espere que eles mudem. Isso faz uma enorme diferença e abre espaço para a evolução futura.

— Tomasz Maciejewski

Concordo que é uma contradição em termos, se você definir a arquitetura como "tudo o que é caro mudar depois", que é a melhor definição que ouvi até hoje. Não concordo com "você deve acertar logo", porém, essa definição é o motivo pelo qual se deve adiar decisões arquiteturais o maior tempo possível (para que elas se tornem tão informadas quanto possível).

— Martin Maat

Respostas:

A palestra de Neal Ford sobre Arquitetura Evolutiva pode ser encontrada aqui.

Parafraseando:

Arquitetura são as decisões que você deseja acertar no início de um projeto, coisas que as pessoas consideram difíceis de mudar. Mas e se construíssemos arquiteturas que esperam mudanças?

Uma arquitetura evolutiva suporta mudanças guiadas incrementais como um primeiro princípio em várias dimensões.

Ele continua descrevendo diferentes cenários arquitetônicos, começando com Big Ball of Mud, arquiteturas em camadas, microkernels e REST e culminando em microsserviços, que ele diz ter n dimensões de capacidade evolutiva (onde n é o número de microsserviços distintos).

Segundo Ford, arquiteturas evolucionárias:

São fracamente acoplados e altamente coesos ,
São compostáveis; componentes podem ser montados para criar novas arquiteturas,
Pode ser alterado gradualmente, sem a necessidade de uma revisão arquitetônica.

Você pode pensar em Arquitetura Evolutiva como uma meta-arquitetura, se quiser; uma arquitetura de arquiteturas. Orientação que dita os princípios de design que promovem a moldagem de argila em vez de pedra.

— Robert Harvey
fonte

Concordo que colocar a palavra "evolucionário" na frente da palavra "arquitetura" significa que não é "arquitetura" no sentido "tradicional".

— 22418 Robert Harvey

Posso pensar mais facilmente nisso como dar um novo nome às mesmas coisas antigas. Toda metodologia de software que me lembro reivindicou adaptabilidade à mudança como uma de suas qualidades. Se isso é único, é principalmente fornecer menos detalhes do que outros sobre como conseguir isso.

— 21818 Jerry Coffin

@Euphoric: Isso não se encaixa no que (por exemplo) Hoare e Dijkstra disseram quando a programação estruturada era nova, nem no que Booch, Meyer, etc. disseram quando o OOP era novo, etc. o que você faria era criar pequenas peças reutilizáveis, para que a maioria das mudanças fosse restrita à arquitetura. Você teria pequenas peças bonitas que poderia facilmente reutilizar de maneiras diferentes, porque a arquitetura mudaria.

— 21818 Jerry Coffin

@Euphoric: Eu diria que sim o oposto: programação estruturada e OOP (para dois exemplos) principalmente se cumprir as suas promessas. É mais difícil dizer muito sobre esse assunto - não espero muitos detalhes em uma nota importante, mas pelo menos de imediato, parece mais hype e menos substância do que a maioria dos antecessores.

— 22818 Jerry Coffin

@Euphoric: em grande parte, sim, eles fizeram. Muito do que é rotineiro hoje em dia teria muito mais probabilidade de falhar usando métodos mais antigos. Eu estive envolvido na construção de alguns sistemas que mal consigo imaginar tentando usar com métodos mais antigos (embora sim, suponho que isso seria possível). Quanto a ler o livro, sim, provavelmente o farei - mas ainda não o fiz.

— 21818 Jerry Coffin

Sim, é uma contradição se você estiver fazendo tudo fácil de mudar indiscriminadamente. Se você precisar adicionar código para tornar algo "mais fácil de alterar" (com "mais fácil" mal definido, como aqui)), você tornou mais difícil a alteração, simplesmente porque adicionou código. Por outro lado, se você souber exatamente o que será alterado, o que é altamente improvável, o código adicional não deverá ser visto como uma complexidade desnecessária.

Tornar as coisas "fáceis de mudar" é provavelmente a principal razão pela qual muitos softwares modernos se tornaram tão inchados e difíceis de mudar.

— Frank Hileman
fonte

É verdade, mas não estou realmente respondendo à minha pergunta.

— Frank Puffer

Hmm, a resposta para sua pergunta é "Sim".

— precisa