Este capítulo possui uma versão mais recente:

Em qualquer cenário, quanto maior a complexidade, maiores são os custos envolvidos. Por isso, tanto na elaboração quanto na avaliação de designs arquiteturais, onde geralmente se busca otimizar o custo – que é um atributo de qualidade – é natural  a busca pelo “mais simples”.

A complexidade tem quatro origens genéricas distintas que devem ser combatidas ou, pelo menos, controladas. São elas: dimensionalidade, interdependência, influência do ambiente e irreversibilidade.

Dimensionalidade

Quanto maior o número de variáveis envolvidas, maior será a dimensionalidade. Por isso, por exemplo, qualquer software com mais features se torna mais complexo. A cada novo processo na organização, menor a simplicidade. Toda exceção suportada aumenta o custo.

Em uma arquitetura monolítica, mais código significa mais complexidade para desenvolvedores. Em uma arquitetura baseada em microsserviços, mais artefatos para distribuir, independentemente, significa mais complexidade para a operação. É parte das práticas de arquitetura determinar onde dimensionalidade maior representa mais problemas. Entretanto, dimensionalidade é uma fonte impossível de evitar em definitivo.

Interdependência

Operações interdependentes demandam mais sincronização. Não raro, a indisponibilidade de um recurso impossibilita o uso de outro, aparentemente não relacionado. É bastante comum que uma performance mais pobre de uma parte de um sistema deixe ele todo “lento”.

A interdependência é “afrouxada” pela utilização de técnicas resilientes e adoção de abstrações.

Influência do ambiente

Sistemas mais “sensíveis” ao ambiente também são mais complexos. Afinal, demandam planejamento de contingências e workarounds.

Falhas em sistemas remotos não raro se convertem em defeitos no sistema em desenvolvimento. Além disso, bem poucas companhias exercem grande influência suficiente no ambiente que operam para mitigar impactos sobre os sistemas (relações conformistas).

Irreversibilidade

Decisões irreversíveis implicam em mais planejamento, cuidado na implementação, testes e, consequentemente, complexidade. Nesse aspecto, deploys mais frequentes, são menores e mais fáceis de desfazer.

Referências bibliográficas

ZANINOTTO, Enrico. From X programming to the X organisation. Trento, Itália: 3Rd Intl Conference Of Xp, 2002. Color. Disponível em: https://martinfowler.com/articles/zaninotto.pdf. Acesso em: 3 jul. 2021.

Compartilhe este capítulo:

Compartilhe:

Comentários

Participe da construção deste capítulo deixando seu comentário:

Inscrever-se
Notify of
guest
0 Comentários
Feedbacks interativos
Ver todos os comentários

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mentorias

para arquitetos de software

Imersão, em grupo, supervisionada por Elemar Júnior, onde serão discutidos tópicos avançados de arquitetura de software, extraídos de cenários reais.

Consultoria e Assessoria em

Arquitetura de Software

EximiaCo oferece a alocação de um Arquiteto de Software em sua empresa para orientar seu time no uso das melhores práticas de arquitetura para projetar a evolução consistente de suas aplicações.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Podcast

Arquitetura de Software Online

55 51 9 9942 0609  |  me@elemarjr.com

+55 51 99942-0609 |  contato@eximia.co

+55 51 99942-0609  contato@eximia.co

0
Quero saber a sua opinião, deixe seu comentáriox
()
x