5 princípios fundamentais da #arquitetura de software

Tempo de leitura: 8 minutos

5 princípios fundamentais da #arquitetura de software

Arquitetos de soluções são os especialistas designados responsáveis pela arquitetura de um sistema, bem como os padrões técnicos (incluindo tecnologias, plataformas, infraestrutura) de um produto específico. Eles definem a visão e sua análise é essencial para a definição, o design, a entrega e o suporte ao longo da vida útil do produto. Portanto, eles precisam entender não apenas o que os negócios precisam, mas também o que é lógico, escalável, econômico e alinhado com os objetivos gerais de tecnologia da organização.

Uma das habilidades vitais de um arquiteto é poder visualizar a arquitetura de vários pontos de vista diferentes: cada uma delas individualmente pode não ser totalmente relevante, mas combiná-las oferece uma visão de alto nível do produto. Esses pontos de vista compreendem princípios, padrões, antipadrões, regras práticas e essenciais para as tomada de decisões em direção a uma direção específica e também para avaliar o sucesso do projeto.

Neste post, abordaremos os princípios de arquiteturas que atribuem a você “afundar ou nadar” em seu papel como arquiteto!

𝕊𝕆𝕃𝕀𝔻 𝕡𝕣𝕚𝕟𝕔𝕚𝕡𝕝𝕖𝕤

Vamos começar com o meu assunto favorito: os princípios do SOLID que se aplicam para projetar e desenvolve um software.

Princípio da responsabilidade única

Cada capacidade do sistema (por exemplo, serviço/módulo/API) deve ter apenas uma responsabilidade e, como tal, um motivo para mudar. Manter as responsabilidades o mais restritas possível significa que os usuários sabem da finalidade pretendida, o que leva a menos erros.

Princípio Aberto-Fechado

Este princípio postula que é preferível estender um comportamento do sistema, sem modificá-lo. Embora muitas vezes não seja uma boa ideia tentar antecipar alterações nos requisitos com antecedência (pois isso pode levar a projetos excessivamente complexos), poder adaptar novas funcionalidades com alterações mínimas nos componentes existentes é essencial para a longevidade do aplicativo.

Princípio da substituição de Liskov

No desenvolvimento de software, isso significa que as classes derivadas devem ser substituídas por suas classes base, mas a semelhança desse princípio com o Design by Contract de Bertrand Meyer é como ela pode ser aplicada à arquitetura distribuída: dois serviços se comunicam de forma eficaz e repetida quando há um contrato comum ‘entre eles, que define as entradas/saídas, sua estrutura e suas restrições. Portanto: dados dois componentes distribuídos com o mesmo contrato, um deve ser substituível por outro componente com o mesmo contrato, sem alterar a correção do sistema.

Princípio de Segregação de Interface

As interfaces/contratos devem ser o mais detalhados possível e específicos do cliente, para que os clientes que se ligam não dependam da funcionalidade que não usam. Isso anda de mãos dadas com o princípio da responsabilidade única: ao quebrar as interfaces, favorecemos a composição separando por papéis/responsabilidades e o desacoplamento por não acoplar módulos derivativos a responsabilidades desnecessárias.

Princípio de Inversão de Dependência

Módulos de alto nível não devem depender dos de baixo nível; ambos devem depender de abstrações. Da mesma forma, as abstrações não devem depender de detalhes, mas os detalhes devem depender de abstrações. Como tal, esse princípio introduz uma abstração de interface entre componentes ou camadas de software de nível superior e inferior para remover as dependências entre eles.

𝕋𝕙𝕖 𝕃𝕖𝕒𝕤𝕥 𝕡𝕣𝕚𝕟𝕔𝕚𝕡𝕝𝕖𝕤

Vou agrupar por convenção de nomenclatura:

O princípio da menor surpresa

O princípio de menos espanto (ou menos surpresa) sugere que uma solução ou abordagem não surpreenderia uma pessoa razoavelmente experiente na área de assunto quando encontrada pela primeira vez (o público pode variar, por exemplo, usuário final, programador, testador etc.). Em termos mais práticos, o princípio visa alavancar o conhecimento pré-existente dos usuários para minimizar sua curva de aprendizado ao usar um módulo; portanto, qualquer coisa com alto fator de imprevisibilidade é um bom candidato para o redesenho.

Aplica-se a todos os aspectos da arquitetura: dos serviços de nomeação, à visualização de interfaces do usuário e ao design do modelo de domínio.

O princípio do menor esforço

Seu princípio (também chamado de Lei de Zipf) deriva de um comportamento humano básico: todo mundo tende a seguir o caminho que é o mais próximo possível do esforço. Por exemplo, se nosso design seguir um padrão específico, o próximo desenvolvedor seguirá o mesmo padrão repetidamente, a menos que haja uma maneira significativamente mais fácil de executar a tarefa; nesse caso, eles serão alterados! Ou, levando isso adiante, uma vez que eles encontram resultados aceitáveis para uma tarefa, não há necessidade imediata de melhorar a solução atual.

Como tal, é imperativo almejar um começo forte, colocando a arquitetura certa no lugar: estabelece altas expectativas e garante que todos entendam que a qualidade não é comprometida no ciclo de vida do projeto e será respeitada em caso de mudanças futuras.

Para mim, a grandeza desse princípio reside no fato de que seus benefícios extrapolam: uma vez que implementamos um design correto, podemos criar uma estrutura arquitetônica que será a base dos próximos sistemas que construímos. Em outras palavras, somos capazes de estabelecer um modelo bem-sucedido e à prova de futuro para os sistemas de software da organização.

𝕋𝕙𝕖 𝕡𝕣𝕚𝕟𝕔𝕚𝕡𝕝𝕖𝕤 𝕠𝕗 ‘𝔼𝕔𝕠𝕟𝕠𝕞𝕚𝕔𝕤’

Esses dois princípios têm um tema comum: o custo de aproveitar ao máximo uma oportunidade e o custo de adiar a tomada de decisões.

O princípio do custo de oportunidade

Toda vez que fazemos uma escolha, há um certo valor que colocamos nessa escolha. O valor tem duas partes: benefícios e custos. O custo de oportunidade de uma escolha é o que desistimos de obtê-la. Para tomar uma boa decisão econômica, queremos escolher a opção com o maior benefício para nós, mas com o menor custo.

Por exemplo, se tivermos duas opções, um sistema interno ou um produto de fornecedor pronto para uso e escolhermos o último, nosso custo de oportunidade será o novo sistema brilhante que nossa equipe de desenvolvimento poderia ter desenvolvido, mas não o fez .

É disso que se trata a arquitetura: ponderar as opções umas das outras e tentar tomar uma decisão informada sobre qual delas agregará mais valor ao projeto. Por exemplo, uma dicotomia muito comum é criar uma solução tática com tempo de comercialização rápido ou uma solução mais estratégica, que agora será mais cara, com o objetivo de alavancá-la em projetos futuros e, portanto, minimizar o custo posteriormente.

Aqui estão alguns pontos a considerar:

  • Qual é o tempo disponível para a análise / avaliação arquitetônica? É bastante desafiador encontrar uma solução, muito menos algumas!
  • Qual é o pipeline de produtos para os próximos 1-3 anos? E que outros projetos estão alinhados? Você consegue ver alguma sinergia?
  • Qual é a sua dívida técnica atual que você poderia enfrentar?
  • E, invertendo isso: quanta dívida técnica nova incorrerá se você buscar uma solução tática?
  • Quais atributos de qualidade tendem a ser os mais importantes para os sistemas em sua organização e como eles serão comprometidos pela solução proposta?
  • Além da equipe de arquitetura, quem mais é uma parte interessada que afetará a decisão? O negócio? Seu chefe? A Autoridade de Projeto Técnico? Quais são os principais objetivos de cada parte interessada? Como você mitigará necessidades conflitantes?

O princípio do último momento responsável

Esse princípio (também conhecido como Custo do atraso) é originado do Lean Software Development e enfatiza a realização de ações importantes e decisões cruciais pelo maior tempo possível. Isso é feito para não eliminar alternativas importantes até o último momento possível, ou seja, aguarde para restringir as opções até que você esteja melhor informado.

Uma estratégia de não tomar uma decisão prematura, mas adiar o compromisso e manter em aberto decisões importantes e irreversíveis até que o custo de não tomar uma decisão se torne maior que o custo de tomar uma decisão.

Uma maneira de mitigar o risco de decidir tarde demais é criar a Prova de Conceitos (POCs) para prototipar as opções alternativas e demonstrar às partes interessadas o que elas estão pedindo.

Conclusão

Os princípios de arquitetura nos ajudam a avaliar as decisões que tomamos ao longo do projeto e também para garantir que estamos alinhados com os objetivos gerais, não apenas para o projeto, mas também a tecnologia da organização.

Espero que este post seja uma fonte de inspiração e orientação em sua jornada arquitetônica de desenvolvimento de software.

Gostou do conteúdo? não deixe de seguir a uebile nas redes sociais, pois toda semana tem post novo aqui no blog com mais dicas para o seu impulso digital.