Aula 3 - Arquitetura SOA e Requisitos Não Funcionais

🎯 Saída do dia: documento (PDF ou .md com diagrama Mermaid/PlantUML embedado) entregue na pasta ponderada/ do seu GitLab individual. Vale nota ponderada — fechar antes do fim dos 90 min.

O dia em que a Netflix parou 💥

Agosto/2008 · 3 dias offline · 4 sintomas do monolito que dispararam a virada arquitetural

🚀

DEPLOY

Deploy bloqueia time

Mudou 1 linha do checkout? Sobe o app inteiro. Janela de deploy semanal vira gargalo de todos os squads.

📈

SCALE

Escala tudo ou nada

Se o módulo de busca fica saturado, você sobe todo o monolito. Custo de infra cresce sem precisão.

👥

PEOPLE

Times se atropelam

Cinco squads no mesmo repositório significa merge conflicts, code reviews atravessadas e branches longas.

🔥

FAULT

Falha em cascata

Bug no recommender derruba o login. Sem isolamento, qualquer exceção pode tombar todo o processo.

📺 O caso · Netflix · agosto/2008

Banco de dados central corrompido · serviço de envio de DVDs paralisado por 3 dias · zero entregas. O monolito que rodava tudo no datacenter próprio fez o problema escalar: uma falha, todo o produto offline.

Resposta histórica: Netflix tomou 2 decisões em sequência — (1) migrar do datacenter próprio para AWS, (2) quebrar o monolito em centenas de serviços independentes. Levou ~7 anos. Hoje qualquer serviço pode cair sem derrubar o catálogo.

🪜 A pergunta da Netflix pós-trauma: "como medir se o sistema novo é bom?". Aí entra a ISO/IEC 25010 — a régua que transformou intuição arquitetural em SLA mensurável. Próximo slide.

ISO/IEC 25010 · 8 eixos de qualidade 📐

A régua de qualidade de software · 8 dimensões mensuráveis · cada RNF cai em uma

🎯1. Functional Suitability

Faz o que diz que faz · completo, correto, adequado.

cobertura ≥ 95% dos use cases

⚡2. Performance Efficiency

Tempo de resposta · throughput · uso de recurso.

latência p99 < 300 ms

🔌3. Compatibility

Coexiste e interopera com outros sistemas (formato, protocolo).

REST/JSON OpenAPI 3.0

👤4. Usability

Aprendível, operável, acessível, agradável.

SUS ≥ 75 / WCAG 2.1 AA

🛡️5. Reliability

Disponibilidade, tolerância a falhas, recuperabilidade.

uptime ≥ 99,9% (≤ 8h/ano)

🔒6. Security

Confidencialidade, integridade, não-repúdio, autenticidade.

OWASP Top-10 mitigado

🛠️7. Maintainability

Modular, reusável, analisável, modificável, testável.

cobertura de testes ≥ 80%

📦8. Portability

Adaptável, instalável, substituível em outros ambientes.

container Docker · 12-factor

📏 Regra de ouro: RNF sem número não é RNF — é desejo. Toda categoria precisa virar SLA mensurável. "Tem que ser rápido" ❌ → "p99 da rota /recomendar < 300 ms com 200 req/s" ✅.

🎬 No próximo slide: como a Netflix transformou cada um destes 8 eixos em ações concretas de engenharia.

Netflix × ISO 25010 · 8 eixos, 8 ações 🎬

Como a Netflix transformou cada eixo de qualidade em decisão de engenharia concreta

Eixo ISO 25010	Ação concreta da Netflix	Por que faz a diferença
🎯 Functional Suitability	Algoritmo de recomendação personalizado · Netflix Prize (US$1M, 2009)	Concurso público para melhorar 10% o RMSE de recomendação. Quando "fazer o que diz que faz" é o produto, vira ciência aberta.
⚡ Performance Efficiency	Open Connect · CDN proprietária dentro de ISPs do mundo todo	Em vez de servir vídeo da AWS, Netflix coloca caches físicos no provedor do usuário. Latência cai de ~200ms para ~10ms.
🔌 Compatibility	App em 1700+ tipos de dispositivo · TVs, consoles, mobile, set-top boxes	Camada de adaptação por device. Mesma API por trás, diferentes encoders/UIs por display. Roda em TV de 2012.
👤 Usability	"Skip Intro", autoplay, capa adaptativa por perfil, preview animado	Cada decisão de UX é A/B testada com milhões de usuários. Engaja sem exigir aprendizado — tela vazia = mais um clique até cancelar.
🛡️ Reliability	Chaos Monkey · derruba serviços em produção de propósito	Se o sistema sobrevive a falhas aleatórias diárias, sobrevive a um datacenter caindo. Resiliência testada, não esperada.
🔒 Security	DRM por título · TLS em tudo · zero-trust interno (BeyondCorp-style)	Cada arquivo de vídeo tem chave de descriptografia única, gerenciada por serviço dedicado. Vazamento de 1 chave ≠ vazamento do catálogo.
🛠️ Maintainability	~700 microsserviços independentes · deploy >1000×/dia	Cada time deploya quando quer. Sem ciclo mensal, sem release coordenado. Bug = revert sem afetar resto.
📦 Portability	Tudo em containers AWS · multi-região · multi-AZ · imagens imutáveis	Imagem Docker é a unidade. Subir nova região é replicar a stack — não reinstalar. Em 2008 isso não existia.

💡 A lição: Netflix não escolheu "vou fazer um sistema bom". Escolheu, por eixo, uma ação técnica observável. Sem números, sem decisão. A ponderada de hoje pede exatamente isso para o seu projeto: 5 RNFs, 5 SLAs, 5 ações de arquitetura.

SOA · 8 Princípios de Erl 🏛️

As regras que separam "tenho serviços" de "tenho arquitetura SOA de verdade"

🔗

1. Loose Coupling

Serviços minimizam dependências. Mudança interna não quebra cliente.

📜

2. Service Contract

Comunicação só pelo contrato (REST/OpenAPI, gRPC). Sem atalho interno.

🛡️

3. Autonomy

Serviço controla seu ambiente e dados. Falha local fica local.

💧

4. Statelessness

Não guarda contexto entre chamadas. Escala horizontal trivial.

♻️

5. Reusability

Lógica de negócio empacotada para reuso por múltiplos consumidores.

🧱

6. Composability

Serviços compõem fluxos maiores (orquestração / coreografia).

🔭

7. Discoverability

Metadados publicados (catálogo, gateway). Cliente acha sem código compartilhado.

🎭

8. Abstraction

Esconde a implementação. Só o contrato é público — interno pode mudar.

📚 Fonte: Thomas Erl · Service-Oriented Architecture: Concepts, Technology, and Design · Prentice Hall. Os 8 princípios são a referência canônica do que distingue SOA de uma simples coleção de APIs.

Monolito × SOA × Microsserviços ⚖️

Mesmos problemas resolvidos em granularidades diferentes — escolha pelo contexto

Dimensão	Monolito	SOA	Microsserviços
Granularidade	Aplicação única	Serviços de negócio (médios)	Serviços pequenos · 1 capacidade
Comunicação	Chamadas in-process	ESB / gateway · SOAP/REST	REST/gRPC + mensageria
Deploy	Tudo de uma vez	Por serviço (com governança central)	Independente por serviço
Equipe	1 time grande no mesmo repo	Times por domínio + arquiteto central	Two-pizza teams autônomos
Falhas	Cascata · pode tombar tudo	Isoladas (com circuit breaker)	Isoladas + bulkhead obrigatório
Dados	1 banco compartilhado	Bancos por serviço (governança)	Database-per-service rígido

🟥 Quando monolito ainda vale: equipe ≤ 6 devs, domínio único, MVP em validação.

🟦 Quando SOA é o ponto certo: múltiplos canais (mobile, web, parceiros), legado para integrar, governança forte.

🟩 Quando microsserviços compensam: tráfego enorme, autonomia por squad, maturidade em DevOps/observabilidade.

UML de Componentes · Anatomia 🧩

5 elementos da notação · esse é o vocabulário que você vai usar na ponderada

⬜ Componente

Caixa com «component». Unidade encapsulada com responsabilidade única.

▫ Porta

Quadradinho na borda. Ponto de comunicação tipado do componente.

🍭 Lollipop

Bolinha = interface fornecida (provided). "Eu ofereço".

🥄 Socket

Meia-lua = interface requerida (required). "Eu preciso".

⊙ Ball-and-socket

Bolinha encaixa na meia-lua: conector. Sinaliza o "plug" entre componentes.

💡 Leia o diagrama: Componente A requer IService · Componente B fornece IService · B requer ILog e IDb que C e D fornecem. Conexão = "fornecedor.lollipop encaixa em consumidor.socket".

Diagrama de Componentes · Netflix Playback 🎬

O que acontece quando você clica em ▶️ Play · 7 componentes orquestrados em <300ms

1️⃣ App pede Play

Cliente envia GET /play/:titleId para o Gateway com token.

2️⃣ Orchestrator resolve

Em paralelo: chama DRM (chave), Catalog (manifesto) e User Profile (progresso).

3️⃣ Devolve URL

Orchestrator monta JSON com streamUrl, licenseUrl e resumeAt.

4️⃣ App stream do CDN

App vai direto ao Open Connect (CDN local) — sem passar pelo gateway.

🔑 Detalhe arquitetural: a setinha roxa do App direto para o CDN é a decisão que faz a Netflix funcionar — se o vídeo passasse por todos os componentes em todo frame, seria insustentável. Componentes orquestram setup; CDN entrega byte.

UML de Deployment · Anatomia 🏗️

7 elementos da notação · responde "onde meu software roda?"

Diagrama UML de deployment com Smartphone (device) executando iOS 17 com NetflixApp.ipa, conectado via HTTPS a uma EC2 Instance executando Docker com api:v3.2

Elemento	O que é · símbolo
📦 Node	Caixa 3D (paralelepípedo). Hardware ou ambiente onde algo executa. "Lugar".
📱 «device»	Estereótipo. Hardware físico: smartphone, servidor, sensor, switch.
⚙️ «executionEnvironment»	Ambiente runtime dentro de um device: Docker, JVM, OS, App Sandbox.
📄 «artifact»	Pacote binário entregável: `.jar`, `.ipa`, imagem Docker, `.exe`.
🔗 «manifest»	Anotação ligando artifact ↔ component: "este artefato implementa o componente X".
🌐 Communication path	Linha entre nodes. Conexão física/lógica entre lugares.
📡 Estereótipo de protocolo	`«HTTPS»`, `«TCP/IP»`, `«AMQP»` · indica como os nodes se falam.

🪆 Aninhamento: nodes contêm execution environments, que contêm artifacts, que manifestam componentes. Vai do físico (servidor) ao lógico (código) sempre de fora pra dentro.

Diagrama de Deployment · Netflix na AWS 🌎

Onde cada componente roda · 4 nodes principais · multi-região · CDN nos ISPs

📦 4 nodes principais

Smart TV/Mobile · AWS us-east-1 · AWS us-west-2 (réplica) · Open Connect Appliance.

🔗 «manifest»

Cada artefato no diagrama de deployment manifesta um componente do diagrama anterior.

📡 2 caminhos físicos

API → AWS (HTTPS, leve) · Stream → Open Connect (HTTPS, pesado, geográfico).

📌 Note como os dois diagramas se complementam: o de componentes mostrou quem fala com quem (lógica). Este de deployment mostra onde cada um vive (infra) — e por isso aparecem coisas que não existiam no anterior: réplicas, regiões, ambientes runtime, protocolos físicos.

Design Arquitetural SOA e RNFs 📓

Atividade ponderada · peso 4 · 10 pontos · 2 entregas · individual · 90 min em sala

ENTREGA 1 · 5 PTS

🏛️

Diagrama de Componentes SOA

Arquitetura SOA do sistema do parceiro em UML de componentes · frontend, backend, BD, integração com APIs externas · texto justificando os pontos.

ENTREGA 2 · 5 PTS

📐

5 Requisitos Não Funcionais

Lista de pelo menos 5 RNFs essenciais · cada um justificado quanto à sua necessidade e à sua relação com a arquitetura SOA proposta.

ENTREGA

📓

PDF ou .md · 90 min

Documento individual (PDF ou Markdown com diagrama PlantUML embedado) na pasta ponderada/ do GitLab pessoal.

📋 Enunciado oficial: "Com base na solução tecnológica que o seu grupo está desenvolvendo para o parceiro de mercado, você deve desenhar a estrutura técnica, com UML de componentes, do sistema e mapear os requisitos de qualidade que garantirão o seu funcionamento."

🧠 Assuntos: Requisitos funcionais e não funcionais · Projeto e arquitetura de sistemas · Histórias de usuários · Engenharia de requisitos · Análise de sistemas de software.

📚 Eixo: Computação · Referência IBM: Component Diagrams ↗

Barema · 2 Entregas × 10 pontos 📐

Cada entrega vale 5 pts · subitens detalhados · ⭐ Excelência sinaliza nota máxima

1️⃣ ARQUITETURA SOA

5,0 pts

a) Blocos principais · 1,5 pt
Identifica corretamente os módulos internos (frontend, backend, banco de dados).
b) Integração com serviços externos · 1,5 pt
Diagrama evidencia conexão com APIs/serviços externos da arquitetura SOA.
c) Diagrama da arquitetura · 1,0 pt
Notação compreensível, conectada de forma lógica (lollipop · socket · portas).
d) Justificação dos elementos · 1,0 pt
Texto explica de forma técnica o porquê da estrutura.
⭐ Excelência: conectar arquitetura desacoplada com escalabilidade do parceiro.

2️⃣ REQUISITOS NÃO FUNCIONAIS

5,0 pts

a) Identificação dos RNFs · até 2,5 pts
Pelo menos 5 RNFs corretos e condizentes com o projeto real do parceiro. 0,5 pt por requisito.
b) Justificativa de cada RNF · até 2,5 pts
Justificativa clara da necessidade + relação com a arquitetura SOA proposta. 0,5 pt por justificativa.
⭐ Excelência: RNFs categorizados pela ISO/IEC 25010 + apontar qual componente do diagrama é responsável por cada um.

💡 Dica: use os 8 eixos da ISO 25010 como checklist. Cada RNF do seu projeto deve cair em um deles, com SLA mensurável.

📌 Fluxo de entrega (individual):

Diagrama em PlantUML (commit do .puml renderiza direto no GitLab — diagrama as code)
Documento em PDF ou .md com diagrama embedado + justificativa + tabela de RNFs com categoria ISO 25010 e componente responsável
Subir o arquivo na pasta ponderada/ do seu GitLab individual (não é o repositório do grupo)

⚠️ Mínimo aceitável: 5 itens base (2× das letras a/b da Arquitetura, mais a/c, mais a/b dos RNFs). Os marcadores ⭐ Excelência nas letras (d) da Arquitetura e (b) dos RNFs levam à nota máxima de cada bloco.

🛠️

Mão na massa · Design Arquitetural SOA + RNFs

90 minutos · 2 entregas · 10 pontos. Cada minuto conta — submissão parcial sempre vale mais que zero.

1️⃣ Abrir editor + arquivo .puml (PlantUML)

2️⃣ Mapear domínio do parceiro em componentes

3️⃣ Entrega 1 · diagrama com blocos + APIs externas

4️⃣ Entrega 1 · justificativa arquitetural ⭐

5️⃣ Entrega 2 · listar 5+ RNFs com SLA mensurável

6️⃣ Entrega 2 · categorizar pela ISO 25010 ⭐

7️⃣ Commit do .puml + doc na pasta ponderada/ do GitLab individual

💡 Estratégia: feche todos os subitens base (a, b, c) das duas entregas primeiro · só depois ataque os ⭐ Excelência (letras d e b).

🎯

A aula 3 me ensinou que...

Arquitetura não é diagrama bonito — é decisão sobre quem fala com quem, sob qual contrato e com qual SLA. Na aula 4 descemos para a camada de dados: stored procedures e functions.

✅ Netflix 2008 · monolito que quebrou

✅ ISO 25010 · 8 eixos de qualidade

✅ Netflix × ISO · 8 ações concretas

✅ 8 princípios SOA de Erl

✅ Mono × SOA × Microsserviços

✅ UML componentes · lollipop / socket

✅ UML deployment · node / artifact / manifest

✅ RNF mensurável (SLA) → componente

✅ Ponte para Stored Procedures · aula 4

Módulo 6 · Engenharia de Software · Aula 3 de 10