Uma das habilidades vitais de um arquiteto é poder visualizar a arquitetura de software 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. Neste post, abordaremos os princípios de arquitetura de software que atribuem seu papel como arquiteto!
Arquitetos de soluções são os especialistas designados responsáveis pela arquitetura de software 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. 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.
Os princípios do SOLID que se aplicam para projetar e desenvolver um software, considerando:
Princípio da responsabilidade única
Cada capacidade do sistema (por exemplo, serviço/módulo/API)
deve ter apenas uma responsabilidade e 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 soxware, 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 de software 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 soxware de nível superior e inferior para remover as dependências entre
eles.
The Least Principles
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 de software: 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 de software 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 soxware da organização.
The principles of “Economics”
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 de software: 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 ou avaliação arquitetônica?
- Qual é o pipeline de produtos para os próximos 1 a 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 de software, 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ê irá mitigar necessidades conflitantes?
O princípio do último momento responsável
Esse princípio (também conhecido como Custo do atraso) é
originado do Lean Soxware 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.
Os princípios de arquitetura de software 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 soxware.
Gostou do conteúdo? Toda semana tem post novo aqui no blog com mais dicas para o seu impulso digital.
