Base para desenvolvimento, descoberta de dados e setup do ambiente.
- Fundamentos: Decisões que custam caro.
- Deep Dive em Estilos: Monolitos Modulares vs Distribuídos.
- De SOA a EDA: A evolução orientada a eventos.
- Sistemas Holônicos Reais: Implementação com Kafka.
- O Papel do Blazor: Consumindo eventos em tempo real.
"Architecture is about the important stuff. Whatever that is."
Arquitetura é gerenciar trade-offs. Não existe "Bala de Prata".
- Desempenho vs Manutenibilidade
- Consistência (ACID) vs Disponibilidade (BASE)
Método oficial do SEI (Software Engineering Institute) para avaliar se uma arquitetura atende aos Quality Attributes (Performance, Segurança, Modificabilidade) desejados.
- "Software Architecture in Practice" (Bass, Clements, Kazman)
- "Clean Architecture" (Robert C. Martin)
// Decisão Arquitetural Implícita:
// Acoplamento forte com Banco de Dados
public class PedidoService {
// Dependência direta = Difícil testar
private SqlConnection _conn = new SqlConnection("...");
public void Criar() {
_conn.Open(); // Bloqueante
// ...
}
}
Um método estruturado (SEI/CMU) para avaliar se a arquitetura suporta os Atributos de Qualidade.
🔍 Conceitos Chave
- Utility Tree: Priorização de requisitos (ex: Segurança (H) > Performance (M)).
- Sensitivity Point: Decisão que afeta DIRETAMENTE um atributo (ex: Criptografia aumenta a Latência).
- Trade-off Point: Decisão que melhora um atributo e piora outro (ex: Cache melhora Performance mas piora Consistência).
- Risk: Decisão não testada ou com impacto incerto.
🎯 O Processo de 4 Fases
- Apresentação: Do Negócio e da Arquitetura.
- Investigação & Análise: Identificar abordagens arquiteturais.
- Cenários: Criar cenários de uso e crescimento.
- Relatório: Riscos documentados e priorizados.
A "Árvore de Utilidade" é a ferramenta #1 para definir o que "Qualidade" significa para O SEU sistema.
Focamos apenas nos cenários (H, H) e (H, M)!
🎯 Sensitivity Point
Uma propriedade do componente que é crítica para alcançar um atributo de qualidade específico.
Exemplo:
"O nível de criptografia (AES-256 vs AES-128)"
Isso é um ponto de sensibilidade para a SEGURANÇA.
⚖️ Trade-off Point
Quando um Sensitivity Point afeta mais de um atributo, de formas opostas.
Exemplo:
"Usar Criptografia Pesada (AES-256)"
- ✅ Melhora Segurança
- 🔻 Piora Latência (Performance)
Como classificar as decisões?
Ao final da análise, cada decisão arquitetural cai em uma categoria:
❌ Risco (Risk)
Decisão que não atende aos cenários de alta prioridade.
Ex: "Usar polling SQL a cada 1s para dashboard real-time (Cenário de Latência < 100ms)."
✅ Não-Risco (Non-Risk)
Decisão validada pelos cenários.
Ex: "Usar WebSockets para notificações push."
Uma lista de Riscos Arquiteturais priorizados. Isso vira o Backlog Técnico!
🏛️ Visão de Negócio (Enterprise)
Define o propósito, o escopo e as políticas do sistema. Não fala de bits e bytes, mas de regras e valor.
Perguntas Chave:
- Para que serve o sistema?
- Quem são os atores (Humanos e Máquinas)?
- Quais são as políticas de negócio (Regras)?
- O que é "Sucesso" para a organização?
📊 Visão de Informação
Define a semântica e a estrutura das informações processadas. É o modelo conceitual dos dados.
- Esquemas de Dados: O que é um "Cliente"?
- Fluxo de Informação: De onde vem, para onde vai?
- Regras de Integridade: "Saldo não pode ser negativo".
{ "id": 1, "status": "ATIVO" }
⬇️
💾
⚙️ Visão Computacional
Decompõe o sistema em Objetos Funcionais e suas Interfaces. Aqui nasce a arquitetura de software lógica.
(Pedidos)
(Estoque)
Foca na decomposição funcional sem se preocupar (ainda) em qual servidor isso vai rodar.
🏗️ Visão de Engenharia
Define a distribuição física e a infraestrutura necessária para suportar os objetos computacionais.
- Clusterização & Load Balancing
- Replicas & Sharding
- Latência de Rede
🔌 Visão Tecnológica
A escolha das ferramentas e padrões concretos. É onde o "martelo bate o prego".
Especificações
- Linguagem: C# (.NET 8)
- Banco: PostgreSQL 15
- Broker: Apache Kafka 3.6
- Front: Blazor WASM
Business Drivers & Políticas
3. Computacional
Políticas de Uso
Distribuição & Infraestrutura
Implementação Concreta
Forças internas ou externas que ditam o sucesso do negócio. A arquitetura deve habilitar esses drivers, não bloqueá-los.
🚀 Time-to-Market
Cenário: "Precisamos lançar features novas toda sexta-feira antes do concorrente."
Impacto Arquitetural:
- Microservices (Deploy independente)
- CI/CD Automatizado
- Feature Toggles
🛡️ Compliance / LGPD
Cenário: "Se vazarmos dados, pagamos 50 milhões de multa."
Impacto Arquitetural:
- Criptografia (At Rest / In Transit)
- Audit Logs Imutáveis
- Mascaramento de Dados
💹 Eficiência de Custo
Cenário: "A conta da AWS está matando nossa margem de lucro."
Impacto Arquitetural:
- Serverless (Pague por uso)
- Autoscaling agressivo
- Spot Instances
📈 Escalabilidade (Black Friday)
Cenário: "No dia 25/11, teremos 100x mais acessos que o normal."
Impacto Arquitetural:
- Cache Distribuído (Redis)
- Processamento Assíncrono (Kafka)
- Stateless Services
Na arquitetura, Persona não é só "nome e idade". É comportamento de IO (Input/Output).
Dona Maria
Usuária Casual- Frequência: Acessa 1x por mês.
- Paciência: Alta (espera 3s).
- Dispositivo: Desktop antigo.
- Arquitetura: Não exige cache agressivo na borda.
Day Trader "Flash"
Power User- Frequência: 50 requests/segundo.
- Paciência: Zero (Latência deve ser < 20ms).
- Dispositivo: Terminal via API.
- Arquitetura: Exige WebSockets, Protocolo Binário (gRPC), In-Memory DB.
O que é?
Descreve a interação entre um Ator e o Sistema para atingir um objetivo.
- Trader seleciona ação PETR4.
- Sistema exibe cotação atual.
- Trader informa quantidade e confirma.
- Sistema valida saldo.
- Sistema executa ordem na Bolsa.
Quem interage com o sistema. Pode ser uma Pessoa (Trader) ou outro Sistema (Banco Central).
Uma funcionalidade ou objetivo específico. Sempre no formato Verbo + Substantivo (ex: "Validar Saldo").
Define o escopo. O que está dentro é software a ser construído; o que está fora são atores externos.
4. Relacionamentos (A Pegadinha!)
<<include>>
Ex: "Sacar Dinheiro" INCLUI "Validar Senha". Sem senha, não há saque.
<<extend>>
Ex: "Sacar Dinheiro" PODE ESTENDER para "Imprimir Comprovante" (se o user pedir).
Para Fazer Pedido, o sistema OBRIGATORIAMENTE exige Pagar e Logar.
O cliente PODE Aplicar Cupom, mas não é obrigado.
- Primário (Cliente): Tem o objetivo. Inicia a ação (lado esquerdo).
- Secundário (API): Fornece serviço. Reage ao sistema (lado direito).
"O sistema DISPARA o ator secundário para completar o objetivo do primário."
Use Case não é Fluxograma!
Não tente desenhar a ordem (1, 2, 3), mostre as dependências.
Como transformar "história" em "especificação"?
- RF01: O sistema deve consultar o saldo disponível do usuário na conta corrente.
- RF02: O sistema deve bloquear o valor da ordem (Preço x Qtd) imediatamente (Reserva de Liquidez).
- RF03: Se saldo insuficiente, o sistema deve retornar erro "402 Payment Required".
Perguntas que o analista precisa fazer
- Capacidade: quantos usuários simultâneos no pico?
- Tempo de resposta: p95/p99 em ms para cada fluxo crítico?
- Throughput: quantas requisições por segundo por módulo?
- Disponibilidade: SLA mensal e janelas de manutenção?
- Dados: volume atual, crescimento e retenção?
- Custo: qual limite de infraestrutura por mês?
Sem NFR, a resposta é "não sei"
"Dá conta" é opinião. NFR é métrica.
Requisitos não funcionais dizem como medir sucesso, falha e risco técnico.
Antes (vaga)
"Nosso sistema dá conta."
- Sem números, sem teste.
- Sem comparação, sem decisão.
- Sem risco explícito, sem plano.
Depois (mensurável)
- Concorrência: 3000 acessos simultâneos no pico.
- Resposta: p95 ≤ 300ms nas rotas críticas.
- Disponibilidade: 99,9% mensal (MTTR ≤ 30 min).
- Retenção: logs por 12 meses, dados por 5 anos.
Agora dá para testar, dimensionar e estimar custo.
Desempenho & Escala
- p95/p99 por fluxo crítico.
- RPS sustentado e burst.
- Planos de escalabilidade (vertical/horizontal).
Disponibilidade & Resiliência
- SLA, SLO e SLI definidos.
- MTTR/MTBF e RTO/RPO.
- Planos de contingência e failover.
Segurança & Compliance
- Criptografia em trânsito e em repouso.
- LGPD: base legal, retenção e descarte.
- Auditoria e trilhas de acesso.
Observabilidade & Operação
- Logs estruturados e traces.
- Alertas com limites claros.
- Dashboards para incidentes.
Pergunta de engenharia
"Quais estruturas e componentes sustentam os requisitos?"
- Quais classes representam o domínio?
- Como as classes se relacionam?
- Onde existem dependências críticas?
- O que é estável x o que muda?
Representação estática
O diagrama de classes mostra estrutura, não fluxo.
Ele responde: "o que existe e como se conecta".
- Identifique as classes (substantivos do domínio).
- Liste atributos (estado que precisa existir).
- Defina operações (comportamentos essenciais).
- Relacione classes (associação, agregação, composição).
- Defina multiplicidades (1, 0..1, 1..*, 0..*).
- Use herança só quando faz sentido.
Legenda rápida
- Classe: retângulo com nome.
- Atributos: dados internos.
- Métodos: ações da classe.
- Associação: linha simples.
- Composição: losango cheio.
- Herança: seta vazada.
Leitura rápida
- Cliente 1..* faz vários Pedidos.
- Pedido 1..* contém Itens.
- Pagamento é base de Cartão (herança).
- Diagrama descreve a estrutura, não o fluxo.
Critérios objetivos
- Requisitos: o stack atende NFRs?
- Time-to-market: velocidade de entrega.
- Manutenibilidade: legibilidade e padrão.
- Ecosistema: libs, comunidade, suporte.
- Custo total: infra + pessoas + operação.
Pergunta chave
"Qual tecnologia reduz risco técnico e acelera valor?"
Tecnologia é meio, não fim. A escolha deve proteger arquitetura e evolução.
Por que C#
- Tipagem forte: menos bugs em produção.
- Performance: runtime maduro e otimizado.
- Ecossistema .NET: bibliotecas sólidas.
- Produtividade: tooling e IDE.
Por que Blazor
- Full stack C#: backend e frontend alinhados.
- Componentes: UI reutilizável e consistente.
- SignalR: updates em tempo real para dashboards.
- Produtividade: menos contexto e menos cola.
Ideal para dashboards robustos feitos do zero.
Dinâmica em UML
- Mostra interações e ordem dos eventos.
- Explicita o fluxo entre UI, serviços e dados.
- Ajuda a validar dependências e latência.
Diagrama de Sequência
Excelente para descrever um caso de uso crítico e seus passos técnicos.
Complementa o diagrama de classes (estrutura) com comportamento.
Leitura rápida
- Fluxo principal do dashboard.
- Mostra onde existe latência.
- Ajuda a definir cache e limites.
Blazor / React / Mobile
Regras de Negócio & Orquestração
Entidades & Repositórios
SQL Server / Postgres
Por que dividir?
- Isolamento (Isolation): Se eu mudar o banco de dados (Oracle para Postgres), a tela do usuário NÃO deve quebrar. A camada de Dados absorve o impacto.
- Testabilidade: Posso testar a Regra de Negócio (Camada 2) sem precisar de um banco de dados real, usando Mocks da Camada 3.
- Segurança: A UI nunca acessa o banco diretamente. Tudo passa pelas regras de validação da camada de Serviço.
Uma camada só pode chamar a camada imediatamente abaixo dela. A UI nunca chama o Banco diretamente!
O Problema do Passado (Silos)
O ERP não falava com o CRM, que não falava com o E-commerce. Integrações ponto-a-ponto viravam um "Espaguete".
A Solução: ESB
O Enterprise Service Bus centraliza e padroniza.
- Roteamento: "Para quem vai essa mensagem?"
- Transformação: XML ↔ JSON ↔ COBOL
- Protocolos: HTTP ↔ FTP ↔ SMTP
O ESB atua como "Hub Universal", evitando conexões N x N.
Ponto de Falha Único e Lógica Centralizada ("Smart Pipes")
Sinais de necessidade
- Vários sistemas legados precisam conversar.
- Funções críticas precisam ser reutilizadas.
- Integrações ponto-a-ponto viraram espaguete.
- Times diferentes mudam em ritmos diferentes.
Benefício principal
SOA permite compor serviços com contratos claros, reduzindo acoplamento entre domínios.
O foco é interoperabilidade, não velocidade bruta.
Caso de uso: "Saúde da comunidade"
- Dashboard agrega Postagens, Comentários e Sentimento.
- Cada domínio publica um serviço com contrato claro.
- O front compõe os dados para gerar insights.
- Nova fonte? Plugou um novo serviço.
SOA (Request/Response)
- Composição de serviços e contratos claros.
- Ótimo para consultas e agregações.
- Consistência imediata e SLA direto.
- Boa para integração com legados.
EDA (Event-Driven)
- Eventos assinc., acoplamento baixo.
- Ótimo para atualizações em tempo real.
- Alta escalabilidade e autonomia.
- Consistência eventual e resiliência.
Coreografia vs Orquestração
🎻 Orquestração (SOA Clássico)
Um maestro (Controller Central) diz:
- Serviço A, faça isso.
- Serviço B, agora faça aquilo.
Gargalo Central! Se o maestro morre, a música para.
💃 Coreografia (Holônico / EDA)
Ninguém manda. Eventos acontecem.
- Holon A emite:
PRODUTO_CRIADO - Holon B (Estoque) ouve e reage.
- Holon C (Marketing) ouve e reage.
Autonomia Total!
Por que importa?
- Modelagem estática define onde o evento nasce.
- Ajuda a mapear entidades e limites do domínio.
- Evita eventos duplicados ou irrelevantes.
Por que importa?
- Mostra por onde o evento passa.
- Define onde capturar, enriquecer e tratar.
- Evidencia latencia e pontos de falha.
Sem modelagem
- Eventos em lugares errados.
- Duplicação de mensagens.
- Tratamentos inconsistentes.
- Dashboards desatualizados.
Com modelagem
- Eventos mapeados por entidade.
- Tratamento padronizado e rastreavel.
- Fluxos claros de captura e consumo.
- Melhor observabilidade.
Não é apenas uma fila. É um Log Distribuído.
Ao contrário do RabbitMQ (que apaga a mensagem após o consumo), o Kafka retém os eventos.
Topic: pedidos-events
Offset 0
Offset 1
Novo!
Utilizando a biblioteca Confluent.Kafka.
📍 Caminho do Evento: ComentarioCriado
Gatilho: Usuário submete comentário via POST /api/posts/{postId}/comments
Destino: Topic Kafka "blog-comentarios-events"
Consumidores: Serviço de Analytics, Serviço de Moderação, Dashboard em tempo real
using Confluent.Kafka;
var config = new ProducerConfig { BootstrapServers = "localhost:9092" };
using var producer = new ProducerBuilder<Null, string>(config).Build();
var mensagem = "{ 'postId': 456, 'comentarioId': 789, 'autor': 'João', 'texto': 'Ótimo post!', 'timestamp': '2024-01-15T10:30:00Z' }";
// Fire and Forget (Assíncrono)
await producer.ProduceAsync("blog-comentarios-events",
new Message<Null, string> { Value = mensagem });
Console.WriteLine("Evento emitido! Comentário publicado no sistema de eventos.");O Serviço de Analytics fica escutando os eventos de comentários...
📊 Caminho do Evento: ComentarioCriado → Analytics
Consumidor: Serviço de Analytics (BackgroundService .NET)
Processamento: Calcula métricas (total de comentários, sentimento, engagement)
Próximo destino: Banco de dados de Analytics + SignalR para Dashboard
var config = new ConsumerConfig {
GroupId = "analytics-group", // Importante para load balancing
BootstrapServers = "localhost:9092",
AutoOffsetReset = AutoOffsetReset.Earliest
};
using var consumer = new ConsumerBuilder<Null, string>(config).Build();
consumer.Subscribe("blog-comentarios-events");
while (true) {
try {
var cr = consumer.Consume(CancellationToken.None);
Console.WriteLine($"Recebi evento de comentário: {cr.Message.Value}");
// Lógica Autônoma de Analytics:
// AtualizarContagemComentarios(postId);
// CalcularSentimento(texto);
// NotificarDashboard(metricas);
}
catch (Exception e) { Console.WriteLine($"Erro: {e.Message}"); }
}Como o Dashboard de Analytics atualiza sozinho?
O Backend (ASP.NET Core) consome o Kafka e avisa o Blazor via SignalR.
🖥️ Caminho do Evento: Kafka → SignalR → Dashboard Blazor
Ponte: SignalR Hub (ASP.NET Core) conectado ao Blazor Server
Destino final: Componente Blazor do Dashboard (atualização em tempo real)
Resultado: Métricas de comentários aparecem instantaneamente na tela
// Componente Blazor Dashboard de Analytics (.razor)
@code {
private List<string> _metricasComentarios = new();
private int totalComentarios = 0;
private double sentimentoMedio = 0;
protected override async Task OnInitializedAsync() {
// Conecta ao Hub SignalR que está "bridged" com o Kafka
hubConnection.On<string>("ReceberMetricaComentario", (metrica) => {
_metricasComentarios.Add(metrica);
totalComentarios++;
// Mágica do Blazor: "Renderize de novo, algo mudou!"
StateHasChanged();
});
}
}Sem StateHasChanged(), o dashboard não atualiza! Cada novo comentário dispara uma atualização visual instantânea.
Cenário: Vocês vão criar um Dashboard Gerencial.
Pesquisa (15 min):
- Como implementar o padrão Producer-Consumer dentro de um BackgroundService (.NET Worker)?
- Como o Blazor Server gerencia o estado (Circuit) diferente do Blazor WASM?
- Desenhe (papel ou Excalidraw) como um evento de "Banco de Dados Atualizado" chegaria até a tela do usuário sem ele dar F5.
Leitura Obrigatória para quem quer ser Senior:
- "Building Microservices" - Sam Newman
- "Enterprise Integration Patterns" - Gregor Hohpe
- "Domain-Driven Design" - Eric Evans