VISÃO ARQUITETURAL

Quais são os objetivos de fazer uma visão arquitetural?

Hey, eu sou a VulcAnna e neste post será abordado o passo a passo para a construção de uma visão arquitetural, com base em preceitos sólidos e fundamentais para resultados promissores e principalmente para um processo satisfatório na sua arquitetura de software.

Primeiro, precisamos ver quais são os benefícios de ter uma arquitetura bem estruturada e como isso pode ser feito.

Let’s go!

Como será feita a construção da arquitetura e quais meios são utilizados na visão arquitetural em prática?

A forma mais conhecida de estruturar uma arquitetura é através de desenhos, que mostram como todo o processo está sendo feito, tem a função de um mapa, e o intuito de fazer com que a equipe saiba o que é aquele projeto, o porque as escolhas iniciais foram tomadas, o que está sendo feito durante o processo e onde vão chegar. Essa forma não é a única a ser inclusa em um projeto, a documentação, aplicação, testes, e feedback caminham boa parte do tempo, em conjunto com esse mapa (que pode ser feito em alguns formatos).

Alguns como o UML, C4, MDL, que serão mencionados ao decorrer deste post, caso queira conferir rapidinho, vai encontra-los no tópico 7.

Para que a Visão Arquitetural serve?

Ajudar com Troubleshooting→ Quando alguma aplicação ou tecnologia começa a dar problemas, é muito comum recorrer ao mapa (quando ele é bem estruturado, fundamentado) para tentar identificar o ponto de origem, a causa raiz dos problemas, olhar para o desenho ajuda a entender e resolver essas causas. Senão no começo do troubleshooting, depois quando quer-se dar uma solução definitiva.

Auxiliar no Estudo para escalabilidade→ Tendo tudo mapeado, a visão de cada camada, a física, lógica, as tecnologias que estão agregadas ali, que dão suporte para todo o produto, tendo também uma clara de visão de tiers, dá para saber como escalar aquele produto, horizontalmente, verticalmente, colocando mais máquinas ou até mesmo aumentando o potencial daquela máquina ou recurso de infraestrutura.

Facilita para identificar quais são os pontos de gargalo.

EXEMPLO TÉCNICO

Você aumentou alguns pontos de microsserviços, então criou outro container com outros microsserviços, talvez o banco de dados vá ser um único, e dependendo das tecnologias do banco de dados sendo utilizadas, você só vai conseguir escalar ele verticalmente, ou seja, aumentando quantidade de memória, aumentando quantidade de recursos computacionais. O mapa de desenho ajuda a olhar os demais componentes que você teria, como um batch (que pega as informações do banco de dados e manda e-mails), talvez esse batch se torne outro ponto de gargalo, a medida que começar a abarrotar mais o DB e ter mais informações para o DB processar.

Direcionar a construção de um produto ou software→ Alinhar com toda a estrutura da empresa: segurança, infraestrutura, dados, negócios, necessidades técnicas em geral.

Documentar a arquitetura→ Muitas empresas precisam de certificações, como CMMI, PCI’s (para operações no mercado financeiro), e muitos desses certificados requerem que você tenha toda a sua arquitetura muito bem documentada, e que o desenho seja o reflexo da realidade.

Tomada de decisões estratégicas→ Uma vez que você tem o desenho bem fundamentado com todos os componentes arquiteturais, é comum que o arquiteto de sistemas ou arquiteto corporativo, recorra aos mapas de cada produto desenvolvido para tentar entender qual que é a dependência de um grande componente arquitetural, como um Enterprise service bus, lightweight gateway, ou de um banco de dados. De repente uma instância de bancos, e quais são os produtos que estão usando eles, para assim tomar uma decisão sobre desativar, evoluir, ou mudar uma tecnologia, e isso pode ser usado para definir uma parceria: Parceiro Oracle, ou parceiro Microsoft?

Isso vai depender das tecnologias que estão sendo alinhadas no projeto, e essa mudança, que é uma grande mudança, vai ter orientação do mapa, que e é o mapa que você criou nessa tomada de decisão.

ENTÃO COMO FAZER ESSE TRABALHO DE DEFINIÇÃO DE ARQUITETURA

Será dividido em 8 fases

1. ENTENDIMENTO
2. 1- Visão estratégica, que é uma visão dos stakeholders, dos tomadores de decisão (vezes do patrocinador do projeto), de como que a empresa vai ter lucro com aquele projeto, se aquele projeto vai resolver uma dor que o cliente tem, que a empresa tem, ou se é alguma coisa nova, como uma nova funcionalidade, por exemplo uma versão mobile. Então pergunte-se: “DO QUE SE TRATA O PROJETO, É ALGO NOVO, OU É UMA DOR A SER RESOLVIDA?”

Como que a empresa vai lucrar, monetizar, esse projeto que está sendo implementado, criado ou evoluído? Reflita à CURTO, MÉDIO e LONGO prazo.

1. 2 VISÃO FUNCIONAL, e aqui estamos falando de uma macrovisão de negócios: Para que serve essa solução, para que serve as funcionalidades, quem são os usuários?

Isso visiona uma perspectiva mais abrangente do ponto de vista de negócios funcional, nesse momento não se pode entrar muito nos detalhes para não perder tempo, mas é importante entender de forma fundamental as grandes funcionalidades, pra que esse sistema vai servir, que tipo de dor esse sistema vai sanar, qual novidade vai trazer. MACRO ENTENDIMENTO DO NEGÓCIO COMO UM TODO.

1.3 Levantamento de arquiteturas (RA’s), que são todas as coisas que impactam direta, ou indiretamente nas decisões arquiteturais. Na sua definição de arquitetura, já em 1.1 e 1.2, tem RA’s, mas aqui (1.3), os RNF’s (Requisitos NÃO funcionais) e RF’s (Requisitos funcionais) estarão inclusos, eles impactam diretamente o desenho, um exemplo: Uma empresa precisa manter o extrato bancário de um cliente por 5, 10 ou 15 anos guardado na base de dados, e tudo bem depois de 4 meses esse serviço se tornar um pouco mais lento para ter esta resposta, demorar para carregar, ou ter até mesmo um outro processo para carregar, o fato é que eu preciso armazenar esse extrato por aproximadamente 15 anos. Esse é um RF que impacta no desenho. Há outros requisitos que entram como requisitos legais (a LGPD), infraestrutura e segurança. Podem haver vários requisitos que impactarão no desenho arquitetural, e o ponto principal, é que: OS REQUISITOS SÃO O ENTENDIMENTO DE TUDO. Eles caminham com as premissas, exemplo simples, se você tem parceria com a Oracle, tudo dentro da sua empresa deve ser conduzido mais ou menos pelo mundo Oracle (barramento Oracle. Desenvolvimento Java ), TER PREMISSAS QUE PRECISAM SER SEGUIDAS.

Tudo em diante, será baseado e deverá seguir a fundamentação deste tópico, caso contrário apenas conseguiremos definições baseados em OPINIÕES, que NÃO será voltado as necessidades reais da companhia e muito menos do projeto, ignorar isso faz com que a arquitetura que acabou de ser criada, torne-se velha e dispensável.

Visão arquitetural

Na pirâmide, um bloco é reforço para o outro, ABORDAGENS que é coerente com o MODELO ARQUITETURAL e que é aderente a todos os FUNDAMENTOS.

2. MODELO ARQUITETURAL, que é uma grande visão de segmentação, Monolitos, Semi monolíticos (microsserviços com funcionalidades específicas monolíticas) ou Micro componentizados (microsserviços).

Vamos para alguns posicionamentos:

Quanto mais micro componentizadas a aplicação, mais complexo o modelo do desenho.

Monolítico mais barata a infraestrutura do projeto ficará.

Então a questão é que tudo tem prós e contras, e é importante sempre se basear em prós e contras, porque caso contrario, vai ter que voltar naquele ponto em que a arquitetura ficará obsoleta muito rápido.

3. ABORDAGENS, tanto de desenvolvimento, quanto arquiteturais, todas as abordagens que se vai utilizar (diga-se o mindset completo), é uma metodologia, um link com as necessidades funcionais. Um especialista é quem vai dizer O QUE, E PARA QUEM É, e o profissional de arquitetura vai dizer o COMO, esse elo das duas coisas é a abordagem, tendo a necessidade de ser coerente. Como o negócio segmenta as funcionalidades da empresa, se segmenta em módulos, deve-se começar a pensar em tudo de forma modular, se pensa em domínios, pode-se segmentar em DDD. Aqui não estamos falando de padrão arquitetural, de como a gente desenha, aqui estamos ainda falando de uma visão de como vamos ESTRUTURAR em cima do Modelo arquitetural, como vamos segmentar o negócio.

PERGUNTAS ADEQUADAS:

Vou ter um módulo “X”, modulo de cadastro de cliente, um domínio, terei um componente, ou evento? O QUE EU VOU TER NO MEU SOFTWARE OU PRODUTO?

Aqui abaixo estão as abordagens

Como:

→ DDD; BDD, BDD, Arquitetura hexagonal, orientação a eventos, orientação a objetos, ou as duas coisas, as vezes usamos mais de uma coisa, como normalmente ao usar DDD junto com orientação a objetos (o que ficaria estranho usado se o DDD fosse usado junto com orientação a eventos).

4. PADRÕES DE ARQUITETURA, agora sim, estamos falando de como vai ser estruturada a aplicação, de cada as camadas que essa aplicação vai ter em cada caixinha da pirâmide, se for usar DDD que foi definido no capítulo anterior, o desenho vai seguir o padrão arquitetural que o DDD traz também, que é a segmentação em camadas, camadas de infra, aplicação, domain- raiz de obrigação, entidades, value, objects. Tem vários padrões arquiteturais, MVC, MVVM, MVP.

Os padrões arquiteturais são formas de segmentação.

5. DEFINIÇÃO DAS TECNOLOGIAS, depois de tudo antes já fundamentado, chegou a hora de falar das tecnologias, que são: As linguagens de programação que serão usadas no projeto inteiro, frameworks, armazenamento de dados (relacional ou não relacional), qual o dev op’s (CI, CD, continous monitouring).

AQUI ESTAMOS FALANDO DAS TECNOLOGIAS PARA DESENVOLVER.

6. COMPONENTES ARQUITETURAIS, essa fase vai dar suporte a todas as fases anteriores, para a solução funcionar, você pode precisar usar um orquestrador de containers, como o Kubernets que é um componente arquitetural, se for usar uma ferramenta audlog (greylog, kibana?). O QUE SERÁ USADO DE FERRAMENTAL?

Ferramenta de cash (ou cachê?). Aqui terá tudo o que é necessário para suportar o desenho. Se em FUNDAMENTOS (CAP1.) eu coloco um pré requisito de que o software tem que ser extremamente rápido mas para comportar um número pequeno de usuários, em MODELO ARQUITETURAL (CAP2.) eu defino que muito provavelmente a melhor opção para estruturar essa aplicação é semi ou completamente monolítica.

7. VISÃO, depois de tudo fundamentado, chegou a hora de desenhar, e poderá ser utilizado UML, C4, MDL, para construir essa visão com o máximo de detalhes possível, é importante que esse desenho seja claro, agradável e engaje quem está lendo, se for bagunçado, cada informação não estiver lógica, com uma sequência, não for fácil de ler, o time técnico ou quem mais for ler, pode ficar confuso e não ficar engajado com o projeto.

FATAL: O efeito será rebote, teremos uma equipe desmotivada.

8- APRESENTAR A VISÃO PARA EQUIPE, todos que estarão em contato com o desenvolvimento produto, serviço, software, vai precisar entender qual foi o seu racional, de forma bem clara e objetiva, o porque você tomou cada decisão, está bastante popular a realização de um Meetup em um auditório, ou em uma área em que as pessoas vão para tomar café. De pé mesmo, mostre a sua visão, o que você fez, apresenta e fala o porque de cada decisão de escolha, ou pode ser uma reunião formal , o mais importante é que essa reunião aconteça. Os técnicos de diversas áreas devem estar presentes, e serem mencionados como integrantes influentes da decisão tomada.

Por exemplo: Usamos MySQL em local x, porque segundo o que a equipe de segurança nos informou, vai ser compatível com tecnologia Y, (que também vai estar documentada no tópico que é necessário). Esse é um momento de feedback da equipe e que tem bastante a função de te fazer melhorar o desenho, é um momento de engajamento e ajuda, fazendo com que todos sejam de fato uma equipe a partes do desenvolvimento do mapa técnico.

ATENÇÃO

Desenhos de arquiteturas prontas não serão úteis, por isso é importante ter os Fundamentos bem desenvolvidos, SEM o FUNDAMENTO bem estruturado, NÃO haverá possibilidade de um projeto viável.

Que a leitura tenha sido de grande valia, nos encontramos em breve, nos próximos posts que serão postados aqui no Medium. Muito obrigada!