AXIS #arquitetura-de-referencia

1. **Links**

1.1. **Planilha de RAs v2.3 da AXIS:** https://docs.google.com/spreadsheets/d/1QJDogD7vKJlLkknOBRiA-1XHh8d3_tqzSywCzKRaADk/edit#gid=1786449769

1.2. **Pasta com insumos e diagramas:** https://drive.google.com/drive/folders/1ozA5v75V2RF4dHnnRVW9gljCS92JTs58

1.3. **Diagramas** https://drive.google.com/drive/folders/1DOA8WuLmPUB4WA5wQgglVXka07f0Li5z?usp=sharing

2. **Motivação**

2.1. A motivação para uma arquitetura de referência do cliente é um guia/documento que apresentará as estruturas e integrações recomendadas de produtos e serviços de TI, para formar uma solução. O objetivo é incorporar as melhores práticas aceitas no setor/mercado, normalmente sugerindo o método de fornecimento ideal de determinadas tecnologias, o que auxiliará o cliente em tomadas de decisões congruentes e fundamentadas.

3. **Sobre o levantamento**

3.1. Autores

3.1.1. Rafael Sousa <rafael.sousa@archoffice.tech>

3.1.2. Daniel Silva <<daniel.silva@archoffice.tech>>

3.1.3. Carlos Pisani <<pisani@archoffice.tech>>

3.2. Data: 04/04/22

4. **Arquitetura Front-End** <<tipo-n (reativo, micro, spa, mobile, web ...)>>

4.1. Desenho

4.2. Quando utilizar?

4.3. Padrão arquitetural aplicado

4.4. Componentes arquiteturais

4.4.1. <<log, cache, fila, criptografia, segurança, toggles, orquestrador de container, recuros de cloud (serverless ou não) etc>>

4.4.1.1. <<por que esta tecnologia deveria ser aplicada? houve uma TC? Houve POC? Colocar os links caso existam>>

4.4.1.2. RAs Atendidos

4.4.1.3. VAs Atendidos

4.5. Stack tecnologica

4.5.1. <<Tecnologia 1>>

4.5.1.1. Racional da escolha

4.5.1.1.1. <<por que esta tecnologia deveria ser aplicada? houve uma TC? Houve POC? Colocar os links caso existam>>

4.5.1.2. RAs Atendidos

4.5.1.3. VAs Atendidos

4.6. Práticas arquiteturais

4.6.1. << bdd | tdd>>

4.6.2. <<ddd | modular | serviços | eventos>>

4.7. Camadas

4.7.1. <<camada 1>>

4.7.1.1. Responsabilidade

4.7.1.2. VAs considerados

4.7.1.3. RAs considerados

4.7.1.4. Tipo de código permitido

4.7.1.5. Tipo de código proibido

4.7.1.6. Tecnologias

4.7.1.7. Uso de algum padrão? Se sim:

4.7.1.7.1. Qual?

4.7.1.7.2. Por que?

4.7.2. <<camada n... >>

4.7.2.1. Responsabilidade

4.7.2.2. VAs considerados

4.7.2.3. RAs considerados

4.7.2.4. Tipo de código permitido

4.7.2.5. Tipo de código proibido

4.7.2.6. Tecnologias

4.7.2.7. Uso de algum padrão? Se sim:

4.7.2.7.1. Qual?

4.7.2.7.2. Por que?

4.8. Dispositivos de automação

4.8.1. Validação de qualidade de código

4.8.1.1. <<se sim qual ferramental>>

4.8.2. Ferramenta para validação de segurança

4.8.2.1. <<se sim qual ferramental>>

4.8.3. Continuous monitoring

4.8.3.1. <<se sim qual ferramental>>

4.8.4. Continuous integration

4.8.4.1. <<se sim qual ferramental>>

4.8.5. Continuous deployment

4.8.5.1. <<se sim qual ferramental>>

4.9. Documentação & governança

4.9.1. <<automatica | manual>>

4.9.2. <<uso de ferramenta? qual>>

4.9.3. <<onde será versionado>>

4.9.4. <<utilizará trunk, git flow ou outro?>>

5. **Arquitetura de Dados**

5.1. Banco de dados cache - Amazon DynamoDB

5.1.1. Quando utilizar?

5.1.1.1. Teorema CAP requerido

5.1.1.1.1. AP A = Disponibilidade; P = Tolerância a particionamento; Se trata de um banco de dados que tem uma alta disponibilidade e tolerância a particionamento. Concluindo assim, que, se trata de um banco extremamente performático, porém eventualmente consistente.

5.1.1.2. Outras considerações

5.1.1.2.1. Quando necessitarmos de performance na coleta de dados, ou seja, próximo da instantaneidade.

5.1.1.2.2. DynamoDB não necessariamente foi feito para trabalhar com Cache, no entanto, atende muito bem essa necessidade, até porque, se trata de um banco de dados como serviço, logo extremamente performático e escalável, ficando com desempenho próximo a de banco de dados In Memory para cache.

5.1.1.2.3. Cache é comumente usado em: - Menus - Gestão de Toogles - Controle de JWTs - Preços - Gerenciamento de sessões - Dados dinâmicos que mudam de tempos em tempos - Cookies do usuário Se trata de informações das quais necessitamos de velocidade, para não impactar a usabilidade e experiência do cliente.

5.1.1.3. Observação:

5.1.1.3.1. Recomendamos uma avaliação de banco não relacional que atenda consistência

5.1.2. RAs atendidos

5.1.2.1. 🔴 RA 06 • Manutenabilidade (15)

5.1.2.2. 🔴 RA 02 • Segurança (13)

5.1.2.3. 🔴 RA 08 • User experience (9)

5.1.2.4. 🟡 RA 04 • Disponibilidade (8)

5.1.2.5. 🔴 RA 09 • Domínio tecnológico da equipe interna (3)

5.1.2.6. 🟡 RA 11 • Observabilidade (3)

5.1.2.7. 🔵 RA 03 • Performance (2)

5.1.2.8. 🔵 RA 12 • Time to market (1)

5.1.2.9. 🟡 RA 05 • Escalabilidade (6)

5.1.2.10. 🟡 RA 10 • Elasticidade (5)

5.1.3. VAs atendidos

5.1.3.1. VA 02 • Senioridade dos times

5.1.3.2. VA 04 • Lock in com parceiros / tecnologias

5.1.3.3. VA 14 • Stack tecnologica predominante

5.1.3.4. VA 23 • Parceiros

5.1.3.5. VA 11 • Sobre volatilidade de dados:

5.1.3.6. VA 13 • Sobre volume de dados:

5.1.3.7. VA 20 • Teorema CAP para cache

5.1.3.8. VA 09 • Serverless

5.1.4. Tecnologia

5.1.4.1. O Amazon DynamoDB é um banco de dados de chave-valor NoSQL, sem servidor e totalmente gerenciado, projetado para executar aplicações de alta performance em qualquer escala. O DynamoDB oferece segurança integrada, backups contínuos, replicação multirregional automatizada, armazenamento em cache na memória e ferramentas de exportação de dados. Banco de dados elástico, então aumenta e diminui sua capacidade dependendo da demanda e não só a capacidade, mas também seu custo.

5.1.5. Finalidade

5.1.5.1. Cache

5.1.5.2. Apesar de não ser um banco de dados In-Memory como redis, o Amazon DynamoDB vai atender de forma satisfatória, cenários dos quais necessitemos de cache e que a informação seja recuperada rapidamente. Ser usado para prover dados transacionais que estão armazenados em banco de dados mais lentos e que são muito consultados, para minimizar o gasto de consultas mais onerosas, visto que, é muito mais rápido e menos custoso achar a informação em um banco não relacional. O pattern Command Query Responsibility Segregation (CQRS) no cenário onde queremos trazer dados transacionais para cache, é indicado, visto que não necessitamos implementá-lo ao pé da letra, mas em partes.

5.1.6. Tipo de consistência

5.1.6.1. Leituras eventualmente consistentes Ao ler dados de uma tabela do DynamoDB, a resposta pode não refletir os resultados de uma operação de gravação concluída recentemente. A resposta pode incluir alguns dados obsoletos. Se você repetir sua solicitação de leitura após um curto período de tempo, a resposta deverá retornar os dados mais recentes.

5.1.6.2. Leituras fortemente consistentes Quando você solicita uma leitura fortemente consistente, o DynamoDB retorna uma resposta com os dados mais atualizados, refletindo as atualizações de todas as operações de gravação anteriores que foram bem-sucedidas. No entanto, essa consistência vem com algumas desvantagens: Uma leitura fortemente consistente pode não estar disponível se houver um atraso ou interrupção na rede. Nesse caso, o DynamoDB pode retornar um erro de servidor (HTTP 500). Leituras fortemente consistentes podem ter maior latência do que leituras eventualmente consistentes. Não há suporte para leituras fortemente consistentes em índices secundários globais. Leituras fortemente consistentes usam mais capacidade de taxa de transferência do que leituras eventualmente consistentes

5.1.6.3. Pode ser eventual e fortemente consistentes. Para Cache o recomendado é Eventualmente Consistentes para uma maior velocidade na coleta dos dados

5.1.7. Estado do dado

5.1.7.1. O Banco de dados DynamoDB tem nesse caso uma finalidade de cache, então o estado do dado não se aplica

5.1.7.2. Se trata de Key Values

5.2. Banco de dados relacional - Amazon Aurora

5.2.1. Quando utilizar?

5.2.1.1. Teorema CAP requerido

5.2.1.1.1. O Aurora se encaixa nas letras C de Consistency + A de Availability: no Teprema CAP). Tendo CA, eles não tem Partition Tolerance. Por se tratar de um serviç gerenciado, não precisaremos se preocupar com replicação. E aqui temos toda a parte de transação, locks de banco, etc, no entanto, o aurora se diz 3 vezes mais rápido que o banco de dados PostgreSQL

5.2.1.2. Outras considerações

5.2.1.2.1. Recomendamos usar no momento de criação de databases o "Aurora PostgreSQL-Compatible Edition", para que assim, tenhamos compatibilidade com um banco de dados mais próximo do domínio interno e que também possibilite a migração para outro serviço de banco de dados

5.2.1.3. Cenários de uso

5.2.1.3.1. • Uso de queries muito grandes e que exige confiabilidade e escalabilidade;

5.2.1.3.2. • Gravação de dados relacionais;

5.2.1.3.3. • Transações a nível de tabela;

5.2.1.3.4. • Tipos de dados (colunas);

5.2.1.3.5. • Consultas complexas;

5.2.1.3.6. • Cenários onde InnoDB é bom;

5.2.1.3.7. • Quando precisar armazenar no mesmo engine;

5.2.1.3.8. • Quando houver variações de storage;

5.2.1.3.9. • Tipos diferentes de indexação;

5.2.1.3.10. • Quando precisar fazer otimizações;

5.2.1.3.11. • Quando precisar de (melhores JOINs, subqueries, CTEs, funções customizadas, estruturas de dados mais poderosas e extensibilidade).

5.2.1.3.12. • Relação direta entre as tabelas e entidades

5.2.2. RAs atendidos

5.2.2.1. 🔴 RA 06 • Manutenabilidade (15)

5.2.2.2. 🔴 RA 02 • Segurança (13)

5.2.2.3. 🔴 RA 08 • User experience (9)

5.2.2.4. 🟡 RA 04 • Disponibilidade (8)

5.2.2.5. 🔴 RA 09 • Domínio tecnológico da equipe interna (3)

5.2.2.6. 🟡 RA 11 • Observabilidade (3)

5.2.2.7. 🔵 RA 03 • Performance (2)

5.2.2.8. 🟡 RA 17 • Portabilidade de Dados (2)

5.2.2.9. 🔵 RA 12 • Time to market (1)

5.2.2.10. 🟡 RA 16 • Uso Micro DataBase (1)

5.2.3. VAs atendidos

5.2.3.1. VA 02 • Senioridade dos times

5.2.3.2. VA 04 • Lock in com parceiros / tecnologias

5.2.3.3. VA 14 • Stack tecnologica predominante

5.2.3.4. VA 22 • Teorema CAP para dados Relacionais

5.2.3.5. VA 23 • Parceiros

5.2.3.6. VA 11 • Sobre volatilidade de dados:

5.2.3.7. VA 12 • Sobre durabilidade de dados:

5.2.3.8. VA 13 • Sobre volume de dados:

5.2.3.9. VA 09 • Serverless

5.2.4. Tecnologia

5.2.4.1. O Amazon Aurora é um banco de dados relacional compatível com MySQL e PostgreSQL criado para a nuvem e que combina a performance e a disponibilidade de bancos de dados empresariais tradicionais com a simplicidade e a economia de bancos de dados de código aberto.

5.2.5. Finalidade

5.2.5.1. Prover dados de forma relacional

5.2.6. Tipo de consistência

5.2.6.1. Transacional

5.2.7. Estado do dado

5.2.7.1. Normalizado

5.3. Banco de dados não relacional - Amazon DynamoDB

5.3.1. Quando utilizar?

5.3.1.1. Teorema CAP requerido

5.3.1.1.1. AP A = Disponibilidade; P = Tolerância a particionamento; Se trata de um banco de dados que tem uma alta disponibilidade e tolerância a particionamento. Concluindo assim, que, se trata de um banco extremamente performático, porém eventualmente consistente.

5.3.1.2. Outras considerações

5.3.1.2.1. O Amazon DynamoDB é um banco de dados não relacional Multi-Model, Key-value Stores e Document Stores. Key-value só podem armazenar pares de chaves e valores, bem como recuperar valores quando uma chave é conhecida. Document Stores armazenamentos de documentos, também chamados de sistemas de banco de dados orientados a documentos, são caracterizados por sua organização de dados livre de esquemas. - Os registros não precisam ter uma estrutura uniforme, ou seja, registros diferentes podem ter colunas diferentes. - Os tipos de valores de colunas individuais podem ser diferentes para cada registro. - As colunas podem ter mais de um valor (matrizes). - Os registros podem ter uma estrutura aninhada. - Os armazenamentos de documentos geralmente usam notações internas, que podem ser processadas diretamente em aplicativos, principalmente JSON. É claro que documentos JSON também podem ser armazenados como texto puro em armazenamentos de valores-chave ou sistemas de banco de dados relacionais. Isso, no entanto, exigiria que o cliente fizesse o processamento lateral das estruturas, e tem a desvantagem de que os recursos oferecidos pelos armazenamentos de documentos (como índices secundários) não estão disponíveis.

5.3.1.2.2. Usaremos para inúmeros cenários onde queremos oferecer a informação para entidades de leituras de uma forma mais performática que seria em um ambiente transacional. Podemos transcrever dados complexos do banco de dados transacional para um não relacional para no momento de sua coleta não fazer lock em tabelas de bancos mais lentos. Não só pra duplicar dados do banco transacional, mas para armazenar dados estes, que não tem relações direta entre outras entidades, como por exemplo logs.

5.3.1.2.3. Crie aplicações em escala na internet compatíveis com metadados e caches de conteúdo de usuário que exija alto nível de simultaneidade e conexões para milhões de usuários, além de milhões de solicitações por segundo.

5.3.1.2.4. Use padrões de design para implantar carrinhos de compras, motores de fluxo de trabalho, rastreamento de estoque e customer profiles. O DynamoDB é compatível com eventos de tráfego intenso e extremamente escalados, podendo lidar com milhões de solicitações por segundo.

5.3.1.2.5. Armazenando grandes volumes de dados sem estrutura definida. Um banco de dados NoSQL não limita os campos, diferente das colunas no SQL. Além disso, você pode adicionar novas propriedades conforme as necessidades dos negócios mudam, sem se preocupar com o impacto nas demais informações armazenadas.

5.3.2. RAs atendidos

5.3.2.1. 🔴 RA 06 • Manutenabilidade (15)

5.3.2.2. 🔴 RA 02 • Segurança (13)

5.3.2.3. 🔴 RA 08 • User experience (9)

5.3.2.4. 🟡 RA 04 • Disponibilidade (8)

5.3.2.5. 🟡 RA 05 • Escalabilidade (6)

5.3.2.6. 🟡 RA 10 • Elasticidade (5)

5.3.2.7. 🔴 RA 09 • Domínio tecnológico da equipe interna (3)

5.3.2.8. 🟡 RA 11 • Observabilidade (3)

5.3.2.9. 🔴 RA 18 • Integrabilidade (3)

5.3.2.10. 🔵 RA 03 • Performance (2)

5.3.2.11. 🟡 RA 17 • Portabilidade de Dados (2)

5.3.2.12. 🔵 RA 12 • Time to market (1)

5.3.2.13. 🟡 RA 16 • Uso Micro DataBase (1)

5.3.3. VAs atendidos

5.3.3.1. VA 02 • Senioridade dos times

5.3.3.2. VA 04 • Lock in com parceiros / tecnologias

5.3.3.3. VA 09 • Serverless

5.3.3.4. VA 14 • Stack tecnologica predominante

5.3.3.5. VA 21 • Teorema CAP para NoSQL

5.3.3.6. VA 11 • Sobre volatilidade de dados:

5.3.3.7. VA 12 • Sobre durabilidade de dados:

5.3.3.8. VA 13 • Sobre volume de dados:

5.3.4. Tecnologia

5.3.4.1. O Amazon DynamoDB é um banco de dados de chave-valor e de documentos NoSQL, sem servidor e totalmente gerenciado, projetado para executar aplicações de alta performance em qualquer escala. O DynamoDB oferece segurança integrada, backups contínuos, replicação multirregional automatizada, armazenamento em cache na memória e ferramentas de exportação de dados. Banco de dados elástico, então aumenta e diminui sua capacidade dependendo da demanda e não só a capacidade, mas também seu custo.

5.3.5. Finalidade

5.3.5.1. Dado não relacional

5.3.6. Tipo de consistência

5.3.6.1. Eventual

5.3.6.2. Ao ler dados de uma tabela do DynamoDB, a resposta pode não refletir os resultados de uma operação de gravação concluída recentemente. A resposta pode incluir alguns dados obsoletos. Se você repetir sua solicitação de leitura após um curto período de tempo, a resposta deverá retornar os dados mais recentes.

5.3.7. Estado do dado

5.3.7.1. Normalizado e desnormalizado

6. **Microcomponentes Containers**

6.1. Contexto geral

6.1.1. Microsserviços em containers é um projeto de arquitetura para construir um aplicativo distribuído. Os microsserviços dividem um aplicativo em serviços independentes, fracamente acoplados e implementáveis ​​individualmente nesse caso utilizando containers. Essa arquitetura permite que cada serviço seja dimensionado ou atualizado usando a implantação de proxies de serviço sem interromper outros serviços no aplicativo. Ele permite a entrega rápida, frequente e confiável de aplicativos grandes e complexos.

6.1.2. Códigos mais complexos, com maior tempo de processamento e alto consumo de recursos. Contrário de serverless, ou seja, tudo aquilo que não pode ser executado no cenário serverless por questões de recursos de infra.

6.1.3. Camadas

6.1.3.1. Stand-Alone

6.1.3.1.1. Controller

6.1.3.1.2. Domain

6.1.3.1.3. Application

6.1.3.1.4. infrastructure

6.1.3.2. API ou BFF: Orquestrado ou Coreografado

6.1.3.2.1. infrastructure

6.1.3.2.2. Model

6.1.3.2.3. Controller

6.1.3.2.4. Queue

6.1.3.3. Microservices

6.1.3.3.1. Façade

6.1.3.3.2. Core

6.1.3.3.3. Data

6.1.3.4. Micro-batch

6.1.3.4.1. Batch-control

6.1.3.4.2. Monitor

6.1.3.4.3. Data

6.1.3.4.4. Core

6.1.3.4.5. File

6.1.3.4.6. Queue

6.2. APIs Sync

6.2.1. Desenho

6.2.2. Quando utilizar?

6.2.2.1. As API síncronas podem ser preferidas em situações em que a disponibilidade do serviço é alta e a baixa latência é uma prioridade. No entanto, um cliente síncrono deve aguardar o retorno de uma chamada de API antes que a execução do código possa continuar. Em alguns casos, esse atraso pode ser percebido pelos usuários do seu aplicativo como latência ou baixo desempenho. Uma falha pode desencadear uma reação em cadeia que resulta em uma negação de serviço para o usuário.

6.2.3. Padrão arquitetural aplicado

6.2.4. Componentes arquiteturais

6.2.4.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

6.2.4.2. Toggles

6.2.4.2.1. Estudo para definição de ferramental de Toggles

6.2.4.3. Log

6.2.4.3.1. Elastic Stack

6.2.4.4. Cache

6.2.4.4.1. Amazon DynamoDB

6.2.4.5. API Gateway

6.2.4.5.1. Amazon API Gateway

6.2.4.6. Orquestrador de containers

6.2.4.6.1. Amazon EKS

6.2.4.7. Cofre de senhas

6.2.4.7.1. AWS Secrets Manager - Centrify

6.2.4.8. Identity Provider

6.2.4.8.1. Em avaliação

6.2.4.9. Ferramental de HSM

6.2.4.9.1. AWS CloudHSM

6.3. APIs Async

6.3.1. Desenho

6.3.2. Quando utilizar?

6.3.2.1. - Tipicamente o microserviço que for desenvolvido para containers, deverá cobrir e ser responsável por 1 ou mais entidades, ou seja, ideal é que seja um domínio, porém podem haver mais. Por se tratar de uma infraestrutura provisionada, logo, não pagamos por execução, mas por hardware.

6.3.2.2. - Quando necessitarmos que uma tarefa transacional com maior complexidade e uso de recursos seja executada.

6.3.2.3. - Quando a requisição necessite de uma resposta imediata do servidor usamos o modelo sincrono, isso é claro, respeitando o timeout default, caso a requisição demore, o recomendado é ir pra uma metodologia Síncrona.

6.3.3. Padrão arquitetural aplicado

6.3.4. Componentes arquiteturais

6.3.4.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

6.3.4.2. Toggles

6.3.4.3. Log

6.3.4.3.1. Elastic Stack

6.3.4.4. Cache

6.3.4.4.1. Amazon DynamoDB

6.3.4.5. API Gateway

6.3.4.5.1. Amazon API Gateway

6.3.4.6. Orquestrador de containers

6.3.4.6.1. Amazon EKS

6.3.4.7. Cofre de senhas

6.3.4.7.1. AWS Secrets Manager - Centrify

6.3.4.8. Identity Provider

6.3.4.8.1. Keycloak

6.3.4.9. Ferramental de Fila

6.3.4.9.1. Amazon SQS

6.3.4.10. Ferramental de HSM

6.3.4.10.1. AWS CloudHSM

6.4. Microservices Coreografado

6.4.1. Desenho

6.4.2. Contexto geral

6.4.2.1. A coreografia é uma técnica para compor serviços de forma distribuída e descentralizada. Não há nó coordenador, cada nó sabe o que deve fazer e como colaborar com seus nós vizinhos. A coreografia pode ser vista de uma perspectiva global, onde não há nós de coordenação.

6.4.3. Quando utilizar?

6.4.3.1. Códigos mais simples ou de complexidade altamente segmentada, necessidade de maior reuso e maior disponibilidade, com maior indice de paralelismo. Suporte a várias formas de escala computacional.

6.4.3.2. Quando necessitar de um encadeamento de serviços encima de uma dada solicitação, por exemplo um pedido de compra, onde vários microservices fará ações diferentes em um mesmo pedido.

6.4.4. Padrão arquitetural aplicado

6.4.5. Componentes arquiteturais

6.4.5.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

6.4.5.2. Toggles

6.4.5.2.1. Estudo para definição de ferramental de Toggles

6.4.5.3. Log

6.4.5.3.1. Elastic Stack

6.4.5.4. Cache

6.4.5.4.1. Amazon DynamoDB

6.4.5.5. API Gateway

6.4.5.5.1. Amazon API Gateway

6.4.5.6. Orquestrador de containers

6.4.5.6.1. Amazon EKS

6.4.5.7. Cofre de senhas

6.4.5.7.1. AWS Secrets Manager - Centrify

6.4.5.8. Identity Provider

6.4.5.8.1. Em avaliação

6.4.5.9. Ferramental de HSM

6.4.5.9.1. AWS CloudHSM

6.5. Microservices Orquestrado

6.5.1. Desenho

6.5.2. Contexto geral

6.5.2.1. A Orquestração pode integrar sistemas de maneira bonita e harmoniosa, responsável por determina a velocidade de integração, chamando o serviço certo na hora certa, relatando cada entrada. Esse método normalmente atua como um coordenador de invocação de serviço em um processo BPM (Business Process Management) ou BPEL (Business Process Execution Language).

6.5.3. Quando utilizar?

6.5.3.1. Necessidade de respostas unitárias mais rápidas, código que necessitem de consistência de dados forte e de maior complexidade.

6.5.3.2. Quando temos que seguir um fluxo específico de forma síncrona, ou seja, decisões centralizadas, um orquestrador (objeto) informa aos participantes quais transações e qual sequencia locais executar.

6.5.4. Padrão arquitetural aplicado

6.5.5. Componentes arquiteturais

6.5.5.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

6.5.5.2. Toggles

6.5.5.2.1. Estudo para definição de ferramental de Toggles

6.5.5.3. Log

6.5.5.3.1. Elastic Stack

6.5.5.4. Cache

6.5.5.4.1. Amazon DynamoDB

6.5.5.5. API Gateway

6.5.5.5.1. Amazon API Gateway

6.5.5.6. Orquestrador de containers

6.5.5.6.1. Amazon EKS

6.5.5.7. Cofre de senhas

6.5.5.7.1. AWS Secrets Manager - Centrify

6.5.5.8. Identity Provider

6.5.5.8.1. Em avaliação

6.5.5.9. Ferramental de Fila

6.5.5.9.1. Amazon SQS

6.5.5.10. Ferramental de HSM

6.5.5.10.1. AWS CloudHSM

6.6. BFFs Sync

6.6.1. Desenho

6.6.2. Contexto geral

6.6.2.1. O BFF disponibiliza alguns ambientes para diferentes grupos de usuários, cada um com diferentes experiências e necessidades de API. Por exemplo, os usuários móveis usam o aplicativo e os usuários de desktop usam o cliente web. Funcionalmente, isso é feito separando cada função no aplicativo ou serviço web, cada uma chamando uma API global.

6.6.3. Quando utilizar?

6.6.3.1. Quando necessitarmos de um back-end sob medida para um dado front-end, este no cenário sincrono, pois o front-end necessita de uma resposta imediata pra cada requisição feita, basicamente atuando como uma camada de orquestração incluindo agregação, computação e composição de dados sob medida para um front-end.

6.6.4. Padrão arquitetural aplicado

6.6.5. Componentes arquiteturais

6.6.5.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

6.6.5.2. Toggles

6.6.5.2.1. Estudo para definição de ferramental de Toggles

6.6.5.3. Log

6.6.5.3.1. Elastic Stack

6.6.5.4. Cache

6.6.5.4.1. Amazon DynamoDB

6.6.5.5. API Gateway

6.6.5.5.1. Amazon API Gateway

6.6.5.6. Orquestrador de containers

6.6.5.6.1. Amazon EKS

6.6.5.7. Cofre de senhas

6.6.5.7.1. AWS Secrets Manager - Centrify

6.6.5.8. Identity Provider

6.6.5.8.1. Em avaliação

6.6.5.9. Ferramental de HSM

6.6.5.9.1. AWS CloudHSM

6.7. BFFs Async

6.7.1. Desenho

6.7.2. Contexto global

6.7.2.1. O BFF é essencialmente uma variante do padrão API Gateway. Ele também fornece uma camada extra entre microsserviços e clientes. Mas, em vez de um único ponto de entrada, ele apresenta vários gateways para cada cliente. Com o BFF, você pode adicionar APIs sob medida para as necessidades de cada cliente, eliminando muito do inchaço que vem ao manter tudo em um só lugar.

6.7.3. Quando utilizar?

6.7.3.1. Quando existe um back-end ainda sob medida, porém que necessita de processamentos encadeados ou mais demorados por meio de Stream (por exemplo) de tal forma, que a aplicação quando finalizada seu processamento, informa o front-end, não o bloqueando, até a resposta ser obtida.

6.7.4. Padrão arquitetural aplicado

6.7.5. Componentes arquiteturais

6.7.5.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

6.7.5.2. Toggles

6.7.5.2.1. Estudo para definição de ferramental de Toggles

6.7.5.3. Log

6.7.5.3.1. Elastic Stack

6.7.5.4. Cache

6.7.5.4.1. Amazon DynamoDB

6.7.5.5. API Gateway

6.7.5.5.1. Amazon API Gateway

6.7.5.6. Orquestrador de containers

6.7.5.6.1. Amazon EKS

6.7.5.7. Cofre de senhas

6.7.5.7.1. AWS Secrets Manager - Centrify

6.7.5.8. Identity Provider

6.7.5.8.1. Em avaliação

6.7.5.9. Ferramental de Fila

6.7.5.9.1. Amazon SQS

6.7.5.10. Ferramental de HSM

6.7.5.10.1. AWS CloudHSM

6.8. Micro-batches agendado (disparo por tempo)

6.8.1. Desenho

6.8.2. Contexto geral

6.8.2.1. Micro-batching é a prática de coletar dados em pequenos grupos ("lotes") com a finalidade de processar os dados. Compare isso com o tradicional "processamento em lote", que normalmente envolve operações em grandes quantidades de dados. O micro-batching é uma variação do batching tradicional em que conjuntos menores de novos dados podem ser processados com mais frequência. O Micro-batching acelera os ciclos para que os dados possam ser carregados com mais frequência, às vezes em incrementos tão pequenos quanto alguns segundos.

6.8.3. Quando utilizar?

6.8.3.1. O batch tem como finalidade principal fazer processamentos em lotes, que não necessitam de input humano para ser disparado. É indicado seu uso em cenário como implementação do padrão CQRS, para sincronização de databases, envio de emails programados, atualização de informações em uma data frequência, logo concluimos, que, deve ser usado para processamento assincrono de tarefas de vários nichos que devem ser repetidas de com uma periocidade de tempos.

6.8.4. Padrão arquitetural aplicado

6.8.5. Componentes arquiteturais

6.8.5.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

6.8.5.2. Toggles

6.8.5.2.1. Estudo para definição de ferramental de Toggles

6.8.5.3. Log

6.8.5.3.1. Elastic Stack

6.8.5.4. Cache

6.8.5.4.1. Amazon DynamoDB

6.8.5.5. API Gateway

6.8.5.5.1. Amazon API Gateway

6.8.5.6. Orquestrador de containers

6.8.5.6.1. Amazon EKS

6.8.5.7. Cofre de senhas

6.8.5.7.1. AWS Secrets Manager - Centrify

6.8.5.8. Identity Provider

6.8.5.8.1. Em avaliação

6.8.5.9. Ferramental de Fila

6.8.5.9.1. Amazon SQS

6.8.5.10. Ferramental de HSM

6.8.5.10.1. AWS CloudHSM

6.9. Micro-batches por evento (disparo por ações <<filas, arquivos etc>>)

6.9.1. Desenho

6.9.2. Contexto geral

6.9.2.1. O Micro-batches por evento é o processo de ação nos dados à medida que são gerados ou publicados. Historicamente, o processamento em tempo real significa simplesmente "processar dados com a frequência necessária para um caso de uso específico". Mas à medida que as tecnologias e estruturas de processamento de fluxo se tornam onipresentes, o que o processamento de fluxo em tempo real significa agora? O tempo de processamento pode ser medido em microssegundos (um milionésimos de segundo) em vez de horas ou dias. O processamento de fluxo de eventos geralmente é visto como complementar ao processamento em lote. O processamento em lote está atuando em um grande conjunto de dados estáticos (“dados em repouso”), enquanto o processamento de Micro-batches de eventos está atuando em um fluxo constante de dados. É por isso que os ambientes de processamento de fluxo de eventos são frequentemente descritos como “processamento em tempo real”.

6.9.3. Quando utilizar?

6.9.3.1. No cenário em que uma cadeia de ações ou processamentos em lotes necessitam ser disparados após um dado evento. Recomendamos em cases, como por exemplo, processamento de pagamentos , detecção de fraudes , detecção de anomalias, manutenção preditiva, análise de IoT, atualizações em banco de dados e mensagens atribuidas em tópicos (STREAM)

6.9.4. Padrão arquitetural aplicado

6.9.5. Componentes arquiteturais

6.9.5.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

6.9.5.2. Toggles

6.9.5.2.1. Estudo para definição de ferramental de Toggles

6.9.5.3. Log

6.9.5.3.1. Elastic Stack

6.9.5.4. Cache

6.9.5.4.1. Amazon DynamoDB

6.9.5.5. API Gateway

6.9.5.5.1. Amazon API Gateway

6.9.5.6. Orquestrador de containers

6.9.5.6.1. Amazon EKS

6.9.5.7. Cofre de senhas

6.9.5.7.1. AWS Secrets Manager - Centrify

6.9.5.8. Identity Provider

6.9.5.8.1. Em avaliação

6.9.5.9. Ferramental de Fila

6.9.5.9.1. Amazon SQS

6.9.5.10. Ferramental de HSM

6.9.5.10.1. AWS CloudHSM

7. **Microcomponentes Serverless**

7.1. Contexto geral

7.1.1. Quando o processamento a ser efetuado for: - Leve - Rápido - Lógica de programação simples - Única Database com poucas entidades (máximo 5), sendo elas de um mesmo domínio.

7.1.2. A arquitetura serverless, é um modelo de execução em que o provedor de nuvem será responsável por executar trechos de código cujos recursos serão alocados dinamicamente e apenas os recursos utilizados para executar esse código específicos. Muitas vezes, o código é executado em um contêiner sem estado e pode ser ativado de várias maneiras, como solicitações HTTP, eventos de banco de dados, serviços de fila, alertas de monitoramento, uploads de arquivos, eventos agendados etc. O código que será enviado ao provedor geralmente é escrito na forma de uma função. Assim, podemos ver que a arquitetura serverless é chamada de "Function as a Service" ou "FaaS".

7.1.3. Padrão arquitetural aplicado

7.1.3.1. Serverless

7.1.4. Obs:

7.1.4.1. Caso funções lambdas forem usadas para situações diferentes do galho superior, o seu custo acabará sendo muito elevado, ou seja, caro.

7.1.5. Boas práticas

7.1.5.1. Concorrência

7.1.5.1.1. Cálculo

7.1.5.1.2. O que isso quer dizer ?

7.1.5.2. Reutilize o ambiente de execução devidamente

7.1.5.2.1. Inicialize fora do handler, pois as conexões com bancos, sdks e etc podem ser reutilizadas por novos contextos, agilizando assim o tempo gasto de processamento e o gasto de recursos de memória

7.1.5.2.2. Obs: Lembrando que também pagamos de acordo com a quantidade de memoria alocada

7.1.5.3. Faça uso de Lazy load

7.1.5.4. Não inicialize variáveis se não for necessário

7.1.5.5. Faça cache de static assets no /tmp

7.1.5.6. Controle e limite suas dependências

7.1.5.6.1. Minimize seu deployment package, somente inclua o que for necessário

7.1.5.6.2. Opte por bibliotecas leves

7.1.5.6.3. Ao invés de importar as dependências por completo por exemplo SDK, importe apenas o que for usar dele.

7.1.5.7. Use Lambda Layers para: AWS SDK e libs comuns entre funções

7.1.5.8. Diga ao SDK o que fazer, defina região e outras variáveis que ele determina de forma automática (porém custosa)

7.1.5.9. Habilite VPC apenas se você precisar acessar um recurso privado

7.1.5.10. Evite encadear funções do Lambda diretamente

7.1.5.10.1. Lambda invocando lambda de forma síncrona significa que você está pagando por ociosidade

7.1.5.10.2. Utilize AWS Lambda Destinations ou AWS Step Functions

7.1.5.11. Analise, observe e monitore tudo

7.1.5.11.1. Utilize CloudWatch Logs Insights (métricas / insights)

7.1.5.12. Melhorar a latência de inicialização (Cold Starts)

7.1.5.12.1. Provisioned concurrency permite que você pré-inicialize as funções

7.1.6. Camadas

7.1.6.1. API ou BFF: Orquestrado ou coreografado

7.1.6.1.1. Core

7.1.6.1.2. Queue

7.1.6.2. Stand-alone

7.1.6.2.1. Domain/Business

7.1.6.2.2. Interface/Façade

7.1.6.2.3. Infraestructure/Technology

7.1.6.3. Microservices

7.1.6.3.1. Application/Façade

7.1.6.3.2. Domain/Core

7.1.6.3.3. Infraestructure/Data

7.1.6.4. Micro-batch

7.1.6.4.1. Batch-control

7.1.6.4.2. Monitor

7.1.6.4.3. Data

7.1.6.4.4. Core

7.1.6.4.5. File

7.1.6.4.6. Queue

7.2. API Sync

7.2.1. Desenho

7.2.2. Quando você invoca uma função de forma síncrona, o Lambda executa a função e aguarda uma resposta, então só é pra ser utilizadas em cenários que o processamento que gera a resposta seja rápido.

7.2.3. Componentes arquiteturais

7.2.3.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

7.2.3.2. Toggles

7.2.3.2.1. Estudo para definição de ferramental de Toggles

7.2.3.3. Log

7.2.3.3.1. Elastic Stack

7.2.3.4. Cache

7.2.3.4.1. Amazon DynamoDB

7.2.3.5. API Gateway

7.2.3.5.1. Amazon API Gateway

7.2.3.6. Orquestrador de containers

7.2.3.6.1. Amazon EKS

7.2.3.7. Cofre de senhas

7.2.3.7.1. AWS Secrets Manager - Centrify

7.2.3.8. Identity Provider

7.2.3.8.1. Em avaliação

7.2.3.9. Ferramental de HSM

7.2.3.9.1. AWS CloudHSM

7.3. APIs Async

7.3.1. Desenho

7.3.2. Quando a chamada não necessita de uma resposta imediata do processamento, ou seja enfileira o evento para processamento e não bloqueia a execução da aplicação, logo o assíncrono permite que a resposta seja separada da solicitação

7.3.3. Componentes arquiteturais

7.3.3.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

7.3.3.2. Toggles

7.3.3.2.1. Estudo para definição de ferramental de Toggles

7.3.3.3. Log

7.3.3.3.1. Elastic Stack

7.3.3.4. Cache

7.3.3.4.1. Amazon DynamoDB

7.3.3.5. API Gateway

7.3.3.5.1. Amazon API Gateway

7.3.3.6. Orquestrador de containers

7.3.3.6.1. Amazon EKS

7.3.3.7. Cofre de senhas

7.3.3.7.1. AWS Secrets Manager - Centrify

7.3.3.8. Identity Provider

7.3.3.8.1. Em avaliação

7.3.3.9. Ferramental de Fila

7.3.3.9.1. Amazon SQS

7.3.3.10. Ferramental de HSM

7.3.3.10.1. AWS CloudHSM

7.4. Microservices Coreografado

7.4.1. Desenho

7.4.2. Quando temos um processamento muito pesado para ser processado posteriormente a requisição

7.4.3. Obs: ótimo case de uso, venda em ecommerce e ou interface reativa

7.4.4. Componentes arquiteturais

7.4.4.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

7.4.4.2. Toggles

7.4.4.2.1. Estudo para definição de ferramental de Toggles

7.4.4.3. Log

7.4.4.3.1. Elastic Stack

7.4.4.4. Cache

7.4.4.4.1. Amazon DynamoDB

7.4.4.5. API Gateway

7.4.4.5.1. Amazon API Gateway

7.4.4.6. Orquestrador de containers

7.4.4.6.1. Amazon EKS

7.4.4.7. Cofre de senhas

7.4.4.7.1. AWS Secrets Manager - Centrify

7.4.4.8. Identity Provider

7.4.4.8.1. Em avaliação

7.4.4.9. Ferramental de Fila

7.4.4.9.1. Amazon SQS

7.4.4.10. Ferramental de HSM

7.4.4.10.1. AWS CloudHSM

7.5. Microservices Orquestrado

7.5.1. Desenho

7.5.2. Quando tenho que seguir uma sequência ao pé da letra

7.5.3. Obs: O ideal é que seja processamento leve e que alimente talvez uma interface sincrona / funcional

7.5.4. Componentes arquiteturais

7.5.4.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

7.5.4.2. Toggles

7.5.4.2.1. Estudo para definição de ferramental de Toggles

7.5.4.3. Log

7.5.4.3.1. Elastic Stack

7.5.4.4. Cache

7.5.4.4.1. Amazon DynamoDB

7.5.4.5. API Gateway

7.5.4.5.1. Amazon API Gateway

7.5.4.6. Orquestrador de containers

7.5.4.6.1. Amazon EKS

7.5.4.7. Cofre de senhas

7.5.4.7.1. AWS Secrets Manager - Centrify

7.5.4.8. Identity Provider

7.5.4.8.1. Em avaliação

7.5.4.9. Ferramental de HSM

7.5.4.9.1. AWS CloudHSM

7.6. BFFs Sync

7.6.1. Desenho

7.6.2. Backends For Frontends (BFF) devem ser usados quando existe a necessidade alta consistência de respostas unitárias ou maior controle de gerenciamento de transações.

7.6.3. Componentes arquiteturais

7.6.3.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

7.6.3.2. Toggles

7.6.3.2.1. Estudo para definição de ferramental de Toggles

7.6.3.3. Log

7.6.3.3.1. Elastic Stack

7.6.3.4. Cache

7.6.3.4.1. Amazon DynamoDB

7.6.3.5. API Gateway

7.6.3.5.1. Amazon API Gateway

7.6.3.6. Orquestrador de containers

7.6.3.6.1. Amazon EKS

7.6.3.7. Cofre de senhas

7.6.3.7.1. AWS Secrets Manager - Centrify

7.6.3.8. Identity Provider

7.6.3.8.1. Em avaliação

7.6.3.9. Ferramental de HSM

7.6.3.9.1. AWS CloudHSM

7.7. BFFs Async

7.7.1. Desenho

7.7.2. Backends For Frontends (BFF) quando temos necessidade de priorizar disponibilidade em alta de volumes de usuários, desacoplamento de serviços, possibilitar retry de requisições e a quando não possui necessidade de respostas iminente.

7.7.3. Componentes arquiteturais

7.7.3.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

7.7.3.2. Toggles

7.7.3.2.1. Estudo para definição de ferramental de Toggles

7.7.3.3. Log

7.7.3.3.1. Elastic Stack

7.7.3.4. Cache

7.7.3.4.1. Amazon DynamoDB

7.7.3.5. API Gateway

7.7.3.5.1. Amazon API Gateway

7.7.3.6. Orquestrador de containers

7.7.3.6.1. Amazon EKS

7.7.3.7. Cofre de senhas

7.7.3.7.1. AWS Secrets Manager - Centrify

7.7.3.8. Identity Provider

7.7.3.8.1. Em avaliação

7.7.3.9. Ferramental de Fila

7.7.3.9.1. Amazon SQS

7.7.3.10. Ferramental de HSM

7.7.3.10.1. AWS CloudHSM

7.8. Micro-batches agendado (disparo por tempo)

7.8.1. Desenho

7.8.2. O micro-batch é uma técnica para agrupar tarefas recebidas a serem executadas em pequenos lotes para obter alguns dos benefícios de desempenho sem aumentar muito a latência de conclusão de cada tarefa. Esse micro-batch pode ser usado em muitas situações em que o batching pode ser usado, mas são necessários tempos de resposta curtos em horários programados para inicialização, fazendo ser possível iniciar o processamento em momentos com menor utilização de recursos.

7.8.3. Componentes arquiteturais

7.8.3.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

7.8.3.2. Toggles

7.8.3.2.1. Estudo para definição de ferramental de Toggles

7.8.3.3. Log

7.8.3.3.1. Elastic Stack

7.8.3.4. Cache

7.8.3.4.1. Amazon DynamoDB

7.8.3.5. API Gateway

7.8.3.5.1. Amazon API Gateway

7.8.3.6. Orquestrador de containers

7.8.3.6.1. Amazon EKS

7.8.3.7. Cofre de senhas

7.8.3.7.1. AWS Secrets Manager - Centrify

7.8.3.8. Identity Provider

7.8.3.8.1. Em avaliação

7.8.3.9. Ferramental de Fila

7.8.3.9.1. Amazon SQS

7.8.3.10. Ferramental de HSM

7.8.3.10.1. AWS CloudHSM

7.9. Micro-batches por evento (disparo por ações <<filas, arquivos etc>>)

7.9.1. Desenho

7.9.2. O micro-batch é normalmente usado em sistemas que recebem um número variável de ações observáveis ao qual esta sempre pronto para processá-las. Esse micro-batch pode ser usado em muitas situações, mas são necessários tempos de respostas curtos com inicialização de processamento advindas de reações projetadas.

7.9.3. Componentes arquiteturais

7.9.3.1. Todos componentes arquiteturais aqui mencionados, tiverem seus respectivos estudos para sua escolha.

7.9.3.2. Toggles

7.9.3.2.1. Estudo para definição de ferramental de Toggles

7.9.3.3. Log

7.9.3.3.1. Elastic Stack

7.9.3.4. Cache

7.9.3.4.1. Amazon DynamoDB

7.9.3.5. API Gateway

7.9.3.5.1. Amazon API Gateway

7.9.3.6. Orquestrador de containers

7.9.3.6.1. Amazon EKS

7.9.3.7. Cofre de senhas

7.9.3.7.1. AWS Secrets Manager - Centrify

7.9.3.8. Identity Provider

7.9.3.8.1. Em avaliação

7.9.3.9. Ferramental de Fila

7.9.3.9.1. Amazon SQS

7.9.3.10. Ferramental de HSM

7.9.3.10.1. AWS CloudHSM

8. Padrões em ambos tipos, Containers e Serverless

8.1. Práticas arquiteturais

8.1.1. TDD

8.1.2. DDD

8.2. Dispositivos de automação

8.2.1. Validação de qualidade de código

8.2.1.1. TC para escolha de ferramental de qualidade de código

8.2.2. Ferramenta para validação de segurança

8.2.2.1. TC para escolha de ferramental de validação de segurança

8.2.3. Continuous integration

8.2.3.1. AWS CodeDeploy (em planejamento de implantação)

8.2.4. Continuous deployment

8.2.4.1. Github Actions (em planejamento de implantação)

8.3. Continuous monitoring

8.3.1. Amazon OpenSearch Service / Elastic Stack

8.4. Documentação & governança

8.4.1. Manual (Swagger não é totalmente integrado)

8.4.2. Docussauros

8.4.3. Github

8.4.4. Git Flow

8.5. Stack tecnológica

8.5.1. .Net Core (C#)

8.5.1.1. Racional da escolha

8.5.1.1.1. Tecnologia Core da empresa

8.5.1.2. RAs Atendidos

8.5.1.2.1. 🔴 RA 06 • Manutenabilidade (15) 🔴 RA 09 • Domínio tecnológico da equipe interna (3) 🔵 RA 12 • Time to market (1)

8.5.1.3. VAs Atendidos

8.5.1.3.1. VA 18 • Negócio é maduro / consolidade / conhecido VA 02 • Senioridade dos times VA 04 • Lock in com parceiros / tecnologias VA 09 • Serverless VA 14 • Stack tecnologica predominante