Arquitetura SOA e Requisitos Não Funcionais

1. Objetivos da aula

Ao final da aula você sabe ler, desenhar e justificar arquiteturas — e transformar "tem que ser bom" em SLA mensurável.

A aula 3 fecha a primeira parte do módulo: como decidir a forma do sistema antes de escrever a primeira linha de banco de dados. Os objetivos específicos são:

• Reconhecer os sintomas de um monolito em escala e o tipo de problema que SOA resolve.
• Dominar os 8 eixos da ISO/IEC 25010 e usá-los como checklist para escrever requisitos não funcionais (RNFs).
• Aplicar os 8 princípios SOA de Thomas Erl para decidir o que vira serviço e o que continua junto.
• Diferenciar Monolito, SOA e Microsserviços e escolher a granularidade certa pelo contexto.
• Ler e desenhar diagramas UML de componentes (lollipop, socket, ball-and-socket, portas).
• Ler e desenhar diagramas UML de deployment (node, device, execution environment, artifact, manifest).
• Escrever um RNF mensurável com SLA e categorizá-lo na ISO 25010.
• Vincular cada RNF ao componente responsável por sustentá-lo.
• Entregar a atividade ponderada: diagrama de componentes do parceiro + 5 RNFs justificados.

2. O dia em que a Netflix parou — agosto/2008

Toda decisão arquitetural relevante começa com uma dor. A da Netflix tem data: 11 de agosto de 2008.

Em agosto de 2008, a Netflix ainda era principalmente uma empresa de aluguel de DVDs por correio. O sistema rodava em um datacenter próprio, em uma aplicação monolítica: um único processo grande, um único banco de dados central, vários times trabalhando no mesmo repositório. Tudo subia junto, tudo escalava junto e — como descobriram naquela semana — tudo parava junto.

O banco de dados central foi corrompido. O serviço de envio de DVDs ficou paralisado por três dias. Zero entregas. Foi o suficiente para a engenharia tomar duas decisões em sequência que levariam aproximadamente sete anos para se concluir:

1. Sair do datacenter próprio e migrar tudo para a AWS.
2. Quebrar o monolito em centenas de serviços independentes, isolados por domínio.

Hoje qualquer serviço da Netflix pode cair — recomendação, busca, perfil — sem derrubar o catálogo nem o playback. Antes, qualquer falha derrubava a empresa.

2.1 Os 4 sintomas do monolito que dispararam a virada

O incidente foi o gatilho, mas a doença era estrutural. Quatro sintomas, presentes em qualquer monolito grande:

2.2 A pergunta que ficou pós-trauma

Resolver o problema não era só "quebrar o monolito". Era preciso medir se o sistema novo era, de fato, melhor. Latência caiu? Disponibilidade subiu? Um deploy individual ficou mais rápido? E aí entra a próxima seção: a ISO/IEC 25010 — a norma internacional que transforma intuição arquitetural em número auditável.

3. ISO/IEC 25010 — a régua de qualidade em 8 eixos

A ISO/IEC 25010 é a norma internacional que define o que é "qualidade de software". Oito categorias, mensuráveis, ortogonais.

Quando alguém pede um sistema "rápido, seguro e fácil de manter", está dizendo três coisas diferentes que entram em três eixos diferentes da ISO 25010. A norma serve como um vocabulário comum entre cliente, produto, arquitetura e dev — e como um checklist para garantir que nenhuma dimensão de qualidade ficou esquecida.

Cada um dos 8 eixos abaixo tem subcaracterísticas e métricas próprias. Aqui apresentamos o eixo, o que ele cobra e um exemplo de SLA mensurável que você pode usar como ponto de partida na ponderada.

4. Netflix × ISO 25010 — 8 eixos, 8 ações concretas

Cada eixo da ISO virou uma decisão técnica observável. É exatamente o nível de concretude que a ponderada cobra.

A tabela abaixo mostra como a Netflix transformou cada um dos 8 eixos da ISO 25010 em uma decisão arquitetural específica. Note que nenhuma é "vou ser melhor" — todas são ações com nome próprio.

5. SOA — Service-Oriented Architecture

SOA não é tecnologia, é estilo arquitetural. Define como serviços de negócio se comunicam por contratos públicos.

SOA (Service-Oriented Architecture) é um estilo arquitetural em que a aplicação é decomposta em serviços — unidades autônomas, com contrato público e responsabilidade clara — que se comunicam por mensagens. Cada serviço encapsula uma capacidade de negócio (não uma função técnica): "gestão de pedidos", "catálogo de produtos", "autenticação", "cobrança".

SOA emergiu na década de 2000 como resposta ao problema dos monolitos corporativos: integrações ponto-a-ponto, dependências cruzadas, dificuldade de evolução. A receita central:

• Serviços de negócio em vez de bibliotecas internas — cada serviço pode ser desenvolvido, implantado e versionado de forma independente.
• Contratos públicos (REST, gRPC, eventos) em vez de chamadas internas — quem consome só conhece a interface.
• Comunicação por mensagens em vez de chamadas in-process — pode ser síncrono (REST/gRPC) ou assíncrono (filas, eventos).
• Governança central de catálogo, segurança e versionamento — para evitar caos quando o número de serviços cresce.

5.1 Por que ainda falamos de SOA em 2026

Microsserviços é, em essência, uma evolução de SOA com granularidade menor e foco em autonomia de time. Mas SOA continua relevante por três motivos:

• Vocabulário base. Os 8 princípios de Erl (próxima seção) são a referência canônica do que distingue uma arquitetura orientada a serviços de uma simples coleção de APIs.
• Granularidade intermediária. Para muitos projetos, "serviços de negócio médios" é a granularidade certa — nem monolito nem 700 microsserviços.
• Integração com legado. SOA é o padrão para conversar com sistemas antigos via ESB (Enterprise Service Bus) ou API Gateway — situação comum em parceiros de mercado reais.

6. Os 8 princípios SOA de Thomas Erl

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

Cada princípio abaixo é, na prática, uma pergunta de revisão que você deve fazer ao seu próprio diagrama. Se a resposta for "não", o serviço provavelmente está mal desenhado.

7. Monolito × SOA × Microsserviços

Não é uma escala "ruim → bom". São três respostas para problemas de escala diferentes.

Os três estilos resolvem o mesmo conjunto de problemas (deploy, escala, time, falhas, dados) em granularidades diferentes. A escolha depende do tamanho do time, da maturidade em DevOps, do volume de tráfego e de quanto você precisa evoluir cada parte de forma independente.

7.1 Quando cada estilo faz sentido

8. UML de Componentes — anatomia da notação

Cinco símbolos. Aprenda esses cinco e você lê (e desenha) qualquer diagrama de componentes.

O diagrama de componentes mostra quem fala com quem na sua arquitetura — quais são as caixas lógicas e como elas se conectam por interfaces. Diferente do diagrama de classes (que mostra estrutura de código) e do de deployment (que mostra onde o software roda), o de componentes mostra a topologia lógica da solução.

8.1 Os 5 elementos da notação

8.2 Como ler o diagrama

O fluxo padrão de leitura é: identifique os componentes, localize as portas, verifique quem fornece (lollipop) e quem requer (socket) cada interface, depois ligue as duas pontas.

8.3 Erros comuns na notação

• Esquecer o estereótipo «component» — sem ele, a caixa pode ser confundida com classe ou módulo.
• Setas em vez de lollipop/socket. Setas são para diagramas de sequência ou de fluxo. Componentes conectam-se por interfaces, não por flechas direcionais.
• Confundir interface fornecida com requerida. Bolinha = forneço. Meia-lua = preciso. Inverter altera o sentido da arquitetura.
• Componente sem responsabilidade única. "Sistema" não é componente. "Serviço de Autenticação" é.

9. Diagrama de Componentes — exemplo Netflix Playback

O que acontece quando você clica em ▶️ Play? Sete componentes orquestrados em menos de 300ms.

Quando o usuário clica em "Play" em um título, o sistema da Netflix precisa, em <300ms, validar a sessão, encontrar o título no catálogo, verificar onde o usuário parou, gerar uma chave de DRM, escolher o melhor servidor de CDN próximo e devolver uma URL de stream. Tudo isso é coordenado por um conjunto de componentes que se conectam por contratos públicos.

9.1 Os 7 componentes do fluxo

1. Netflix App (smart TV, mobile, web) — cliente que dispara o pedido.
2. API Gateway · Zuul — recebe a requisição, valida token, aplica rate limit e roteia.
3. Playback Orchestrator — coordena as chamadas paralelas a DRM, Catalog e User Profile.
4. DRM Service — gera/valida chave de descriptografia (Widevine, PlayReady, FairPlay).
5. Catalog Service — devolve manifesto do vídeo (URLs HLS/DASH, ABR, legendas).
6. User Profile Service — devolve progresso, idioma e preferências do usuário.
7. Open Connect (CDN) — servidor de cache dentro do ISP que entrega o stream em si.

9.2 Os 4 passos do clique ao stream

9.3 Diagrama renderizado em PlantUML

Esse é o tipo de diagrama que você vai entregar na ponderada — gerado a partir de algumas linhas de código PlantUML, sem precisar desenhar à mão.

@startuml netflix-playback-components
package "Cliente" {
  [Netflix App] as App
}
package "Backend (AWS us-east-1)" {
  [API Gateway · Zuul]        as GW
  [Playback Orchestrator]     as Orch
  [DRM Service]               as DRM
  [Catalog Service]           as Cat
  [User Profile Service]      as Prof
}
cloud "Externo · ISP" {
  [Open Connect (CDN)] as CDN
}
App  --( GW   : IHttp
GW   --( Orch : IPlayback
Orch --( DRM  : ILicense
Orch --( Cat  : ICatalog
Orch --( Prof : IProfile
App  --( CDN  : IStream
@enduml

10. UML de Deployment — anatomia da notação

Sete elementos. Responde à pergunta: "onde meu software roda fisicamente?".

Enquanto o diagrama de componentes mostra quem fala com quem (lógica), o de deployment mostra onde cada um vive (infraestrutura). É nele que aparecem servidores, regiões, containers, dispositivos e os protocolos físicos que conectam tudo.

10.1 Os 7 elementos da notação

10.2 Aninhamento — do físico ao lógico

Exemplo concreto: um «device» Smartphone contém um «executionEnvironment» iOS 17 (App Sandbox), que contém um «artifact» NetflixApp.ipa v8.42.0, que «manifest» implementa o componente Netflix App visto no diagrama de componentes.

11. Diagrama de Deployment — exemplo Netflix na AWS

Onde cada componente vive: 4 nodes principais, multi-região e CDN dentro dos ISPs.

Pegamos os 7 componentes do exemplo do Playback (seção 9) e perguntamos: onde cada um deles roda?. A resposta é o diagrama de deployment.

11.1 Os 4 nodes principais

• «device» Smart TV / Mobile — hardware do usuário, com OS (iOS, Android, Tizen) hospedando o artifact NetflixApp v8.42 que «manifest» o componente Netflix App.
• «node» AWS · us-east-1 — a região primária. Hospeda o execution environment Docker/EKS rodando os artifacts playback-svc:v3, drm-svc:v1, catalog-svc:v5 e profile-svc:v2. Também contém o cluster Cassandra com o artifact metadata.db (sharded).
• «node» AWS · us-west-2 — réplica para failover. Stack idêntica replicada continuamente. RPO < 1s · RTO < 60s.
• «device» Open Connect Appliance (no ISP) — hardware dedicado da Netflix instalado dentro do provedor de internet do usuário. Roda FreeBSD + nginx, com cache dos títulos mais populares.

11.2 Os 2 caminhos físicos

11.3 Diagrama renderizado em PlantUML

@startuml netflix-aws-deployment
node "Smart TV / Mobile <<device>>" as Device {
  artifact "NetflixApp v8.42" as App
}
node "AWS · us-east-1 <<node>>" as East {
  node "EKS · Docker <<executionEnvironment>>" as EKS {
    artifact "playback-svc:v3"
    artifact "drm-svc:v1"
    artifact "catalog-svc:v5"
    artifact "profile-svc:v2"
  }
  database "Cassandra Cluster\nmetadata.db (sharded)" as Cassandra
}
node "AWS · us-west-2 <<node>>\n(réplica · failover)" as West {
  artifact "stack idêntica\nRPO < 1s · RTO < 60s" as Replica
}
node "Open Connect Appliance <<device>>\n(dentro do ISP)" as OCA {
  node "FreeBSD + nginx <<executionEnvironment>>" as FreeBSD {
    artifact "video-cache\n(Top-N popular titles)" as Cache
  }
}
Device --> East : <<HTTPS>> API
East   ..> West : <<replicação multi-região>>
Device --> OCA  : <<HTTPS>> stream HLS/DASH
@enduml

12. RNF mensurável — transformando desejo em SLA

Um RNF que não pode ser testado é uma opinião. SLA é o que separa requisito de desejo.

Um Requisito Não Funcional (RNF) descreve como o sistema deve se comportar — não o que ele faz, mas com qual qualidade. A regra prática para escrever um RNF útil tem três partes:

1. Categoria ISO 25010 — em qual dos 8 eixos o RNF cai.
2. Métrica observável — número, unidade e ferramenta de medição.
3. Condição de carga / contexto — sob qual cenário o número precisa ser cumprido.

12.1 Antes e depois — RNFs reescritos

12.2 Template para escrever um RNF

13. Vinculando RNF ao componente responsável

Cada RNF precisa de um endereço. Sem dono, não há quem garanta.

Um RNF que não está ligado a um componente do diagrama é órfão — ninguém implementa, ninguém testa, ninguém revisa em PR. A boa prática (e o critério de excelência da ponderada) é manter uma tabela de vínculo que conecte cada RNF a um componente específico responsável por sustentá-lo.

13.1 Exemplo de tabela RNF → Componente (caso Netflix)

14. Atividade ponderada — descrição completa

Peso 4 · 10 pontos · 2 entregas · individual · 90 minutos em sala.

14.1 As 2 entregas

14.2 Formato e local de entrega

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

15. Barema detalhado — 2 entregas × 10 pontos

Cada entrega vale 5 pts. Subitens detalhados. ⭐ Excelência sinaliza nota máxima.

15.1 Entrega 1 — Arquitetura SOA (5,0 pts)

15.2 Entrega 2 — Requisitos Não Funcionais (5,0 pts)

16. PlantUML passo a passo

Diagrama-as-code: você commita o .puml, o GitLab renderiza automaticamente.

O PlantUML é uma linguagem textual para descrever diagramas UML. Você escreve um arquivo .puml (ou .plantuml), commita no GitLab, e o próprio GitLab renderiza o SVG na visualização do arquivo. Vantagens: o diagrama vive junto do código, evolui com PRs e tem histórico no git.

16.1 Hello world em componentes

@startuml
component "Frontend Web"  as FE
component "Backend API"   as BE
database  "PostgreSQL"    as DB

FE --( BE : IRest
BE --( DB : ISQL
@enduml

Esse trecho já cobre o requisito mínimo de "blocos principais": frontend, backend e banco. Cole no GitLab dentro de um .puml e o diagrama renderizado é exatamente esse.

16.2 Adicionando integração externa

@startuml
package "Parceiro de Mercado · Interno" {
  component "Frontend Web"   as FE
  component "Backend API"    as BE
  database  "PostgreSQL"     as DB
}

cloud "Serviços Externos" {
  component "Stripe API"     as Stripe
  component "SendGrid"       as Mail
  component "Google Maps"    as Maps
}

FE --( BE     : IRest
BE --( DB     : ISQL
BE --( Stripe : IPayment
BE --( Mail   : IMail
BE --( Maps   : IGeo

note right of Stripe
  «external»
  cobrança recorrente
end note
@enduml

Esse trecho atende a letra (b) — Integração com serviços externos — e fica claramente separado do "interno" pelo package e do "externo" pelo cloud.

16.3 Documento .md com diagrama embedado

Em um arquivo Markdown no GitLab, você pode embedar o PlantUML diretamente entre cercas de código plantuml:

# Ponderada Aula 3 · <Seu Nome>

## 1. Diagrama de Componentes

```plantuml
@startuml
component "Frontend Web" as FE
component "Backend API"  as BE
database  "PostgreSQL"   as DB
FE --( BE : IRest
BE --( DB : ISQL
@enduml
```

## 2. Justificativa Arquitetural

A separação em frontend, backend e banco segue o princípio de
**Loose Coupling** (Erl, princípio 1): cada componente tem
contrato público e pode ser evoluído de forma independente...

## 3. Requisitos Não Funcionais

| RNF  | Categoria ISO  | SLA              | Componente |
|------|---------------|------------------|------------|
| RNF-01 | Performance | p99 < 300ms     | Backend API |
| RNF-02 | Reliability | uptime ≥ 99,9% | Backend API |
| ...    | ...         | ...              | ...        |

17. Checklist de entrega

Antes de fechar o GitLab, valide cada item desta lista.

18. Armadilhas comuns (e como evitar)

Padrões que aparecem todo trimestre. Reconheça antes de cair.

18.1 No diagrama

• Componente "Sistema" no centro. Indica que você não decompôs nada. Cada componente precisa ter responsabilidade única. Se "Sistema" abrange tudo, separe em frontend, backend e banco no mínimo.
• Setas direcionais em vez de lollipop/socket. Diagrama de componentes não usa setas — usa interfaces tipadas. Setas pertencem a diagramas de sequência ou de fluxo.
• "Frontend → Backend → Banco" e nada mais. Falta a integração externa (item b do barema, 1,5 pt). Adicione pelo menos um serviço externo (pagamento, email, mapas, autenticação social).
• APIs externas sem estereótipo. Use «external» ou agrupe em cloud para deixar claro que estão fora do controle do parceiro.

18.2 Nos RNFs

• "Tem que ser rápido / seguro / fácil". Sem número, é desejo. Reescreva com métrica, unidade e condição de carga.
• 5 RNFs todos do mesmo eixo. Cobre mais espaço da ISO 25010 — pelo menos 3 eixos diferentes nos 5 RNFs.
• RNF sem componente responsável. Perde o ⭐ de excelência. Sempre aponte qual caixa do diagrama sustenta o RNF.
• Copiar a tabela do Netflix. O RNF tem que ser do seu parceiro. "DRM por título" não faz sentido para um sistema de gestão de estoque.

18.3 Na entrega

• Subir no GitLab do grupo. A ponderada é individual. Subir no grupo zera a entrega.
• Esquecer de commitar o .puml. Sem o arquivo fonte, perde "diagrama as code" e dificulta a correção.
• PDF sem o nome do aluno. Em entregas individuais, identifique-se sempre.
• Deixar para os 5 minutos finais. O git tem fila e CI; commit e push podem demorar. Tente fechar 10 min antes do prazo.

19. Referências e leituras complementares

As 4 leituras obrigatórias dos autoestudos + 4 sugeridas + bibliografia canônica.

19.1 Obrigatórias (autoestudos pré-aula)

• RNFs no contexto de SOA — ThinkMind (artigo, seção II item B)
• SOA Reference Architecture — TOGAF / Open Group
• Simplified UML deployment diagram of a generic enterprise-scale SOA — ResearchGate
• Layers of SOA Reference Architecture — ResearchGate

19.2 Sugeridas

• SOA — Visão da AWS
• SOA — Visão da Microsoft (.NET)
• SOA — Visão da IBM
• Norma ISO/IEC 25010 — iso25000.com

19.3 Bibliografia canônica

• Erl, T. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall, 2005.
• Erl, T. SOA Principles of Service Design. Prentice Hall, 2007.
• Newman, S. Building Microservices. 2ª ed. O'Reilly, 2021.
• Richards, M.; Ford, N. Fundamentals of Software Architecture. O'Reilly, 2020.
• IBM Docs · Component Diagrams

19.4 Ferramentas

• PlantUML — site oficial (sintaxe completa, exemplos, server online).
• PlantUML · Component Diagrams (referência específica para a ponderada).
• PlantUML · Deployment Diagrams.
• VS Code · extensão PlantUML de jebbs (preview ao vivo).