Flexibilidade: Um princípio de Arquitetura de Software

Image for post
Image for post
Sydney Opera House — Créditos da imagem

Uma capacidade importante para as empresas prosperarem, crescerem e até sobreviverem é a capacidade de reagir e se adaptar à mudança. Isso se relaciona com as necessidades dos clientes, a expansão para novos mercados ou a utilização das mais recentes e melhores tecnologias. Os sistemas de software dos quais as empresas dependem devem refletir isso.

Uma arquitetura de software flexível é essencial nesse sentido. Aqui nós discutimos alguns trade-offs que devem ser considerados e dando uma visão geral em alguns estilos arquitetônicos adequados.

Os Princípios da Boa Arquitetura

Já nos tempos antigos, os princípios de uma arquitetura bem projetada eram conhecidos e descritos, por exemplo, pelo arquiteto romano Vitruvius em ‘De architectura’; “ Firmitas, utilitas, venustas”. A arquitetura deve ser estável, útil e bonita.

Image for post

Para a arquitetura de software, os princípios de estabilidade e utilidade representam a resiliência e o ciclo de vida do sistema, e estão intimamente relacionados a como a arquitetura resiste que permite mudanças ao longo do tempo. O princípio da beleza surge quando a arquitetura está em harmonia com o ambiente e sem desordem e complexidade desnecessárias.

Uma arquitetura de software flexível é capaz de se adaptar às mudanças nos requisitos de ambiente e usabilidade, sem abranger mudanças estruturais. Também é livre de estruturas rígidas que de outro modo obstruiriam a evolução e o crescimento funcional.

Uma arquitetura flexível permite a criação

Todos os sistemas possuem uma estrutura e uma composição, que juntas definem a arquitetura. Composição aqui refere-se aos componentes de software incluídos e a estrutura de como esses componentes se comunicam e interagem uns com os outros. A arquitetura é deliberada e conhecida, ou acidental e cresceu ao longo do tempo.

Uma abordagem sistemática e projetada produzirá uma arquitetura mais flexível, ao invés de permitir que a arquitetura evolua organicamente sem qualquer projeto geral e consideração de como ativar e resistir a mudanças. No entanto, o equilíbrio entre estes e o risco de engenharia antecipada será sempre uma questão a considerar.

O projeto de uma arquitetura flexível também é bem adaptado às metodologias de desenvolvimento ágil, onde as decisões referentes aos vários componentes do sistema podem ser adiadas até que sejam necessárias. Uma arquitetura flexível permite interfaces que se integram com componentes atuais e futuros. Isso também reduz o risco, já que os componentes mais complexos do sistema podem ser priorizados precocemente. Assim, nem todos os requisitos precisam ser definidos antes que o desenvolvimento possa ser iniciado. No entanto, observe que é essencial garantir que o ponto de vista arquitetônico esteja mais distante do que apenas a próxima iteração. Isso é para evitar o crescimento implícito de um sistema orgânico, onde as mudanças serão caras.

Da mesma forma, uma arquitetura flexível é uma etapa essencial para DevOps e implantação contínua (continuous deployment). Ser capaz de atualizar ou personalizar apenas as partes necessárias de um sistema, simplifica e otimiza os pipelines de implantação. Normalmente, haverá vários pipelines de desenvolvimento e implantação, simplificá-los economizará tempo e esforço a longo prazo. As melhores soluções reduzem os riscos relacionados à implantação, implementando uma arquitetura de núcleo flexível que permite extensões e upgrades contínuos.

Contratos de Arquitetura

Todas as arquiteturas têm seus prós e contras, implícitos ou explícitos, entre flexibilidade, complexidade e desempenho. No triângulo das considerações de projeto de arquitetura, concentrar-se em dois desses atributos provavelmente terá um impacto negativo no terceiro.

Image for post

Projetar uma arquitetura altamente flexível e eficiente proporcionará uma arquitetura complexa, uma arquitetura com alto desempenho e baixa complexidade será rígida e inflexível, e uma arquitetura complexa e flexível provavelmente não gerará alto desempenho.

O conhecimento do domínio e o tempo suficiente são a base para adaptar a arquitetura do sistema com a quantidade certa de flexibilidade, quando necessário. Outras partes do sistema podem, então, atender a requisitos como alto desempenho e baixa complexidade, conforme necessário. Os componentes de desempenho freqüentemente encapsulam a funcionalidade do domínio central e são complexos por projeto, mas freqüentemente também requerem menos flexibilidade e possuem uma estrutura fechada.

As escolhas de design e implementação são frequentemente feitas com base em premissas falsas, como a facilidade de acessibilidade, benefícios mal percebidos que encurtam o tempo de desenvolvimento ou a falta de uma visão de longo prazo. Isso muitas vezes resultará em uma arquitetura inflexível que limita as possibilidades de futura adaptação e crescimento. A implementação de uma solução com apenas os requisitos atuais em mente irá restringir o possível espaço de expansão futuro sem retrabalho considerável.

Configuração ou Personalização

A flexibilidade pode ser facilitada pela configuração e personalização. No entanto, existem algumas diferenças significativas entre essas duas abordagens. Onde a configuração é geralmente um processo de implantação, a personalização é tipicamente um esforço maior que requer conhecimento técnico. A configuração pode incluir a especificação de um caminho de instalação ou outros meta-dados que alteram os parâmetros técnicos ou a aparência de um sistema. A personalização geralmente requer tarefas técnicas e esforço de desenvolvimento, como a criação de um novo plug-in, a adaptação de um conector de API ou a adição de uma nova interface de integração.

Usar toggles ou sinalização de recurso é uma forma de configuração que está ganhando popularidade, permitindo a implantação gradual de recursos para usuários específicos ou para propósitos de implantação. Isso, de certa forma, preenche a lacuna entre a configuração e a personalização, mas cuidado com os perigos do aumento dos esforços de manutenção e teste. Um pipeline de implementação que funcione bem é crucial para tornar isso viável.

Uma solução baseada principalmente na configuração normalmente não oferece flexibilidade para se adaptar ao longo do tempo. Da mesma forma, qualquer customização não deve requerer mudanças na arquitetura principal, já que esse recurso deve ser embutido. A customização deve ser ativada desde o início, pois será necessário muito esforço de desenvolvimento para incluir retroativamente (se possível). Sistemas que são inflexíveis frequentemente também convidam a consertos rápidos que acumularão dívida técnica e bagunçarão a base de código. Com o tempo, isso levará a maiores custos de manutenção e redução da velocidade de implementação.

Algumas observações finais

Certamente há cenários em que o foco inicial na flexibilidade da arquitetura é de menor importância. No entanto, lembre-se de que até mesmo um aplicativo independente que nunca deveria ser alterado pode, de repente, ser obrigado a integrar-se a sistemas externos ou evoluir com novas funcionalidades.

Para a maioria dos sistemas críticos em larga escala e de negócios, é necessário investir esforços no projeto de uma boa arquitetura para garantir que eles possam possibilitar mudanças, alcançar a longevidade e ter uma boa aparência em todos os estágios de seus ciclos de vida.

⭐️ Créditos

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store