Aula 3 — Plano de Ensino — SOA e Requisitos Não Funcionais

Identificação

Curso

Engenharia de Software

Módulo

Projeto 6 — SOA Mobile

Aula

3 de 10

Carga horária do dia

6h (2h + 2h + 2h)

Modalidade

Presencial · Metodologia ativa

Pré-aula

Autoestudo guiado

Resumo

A aula 3 sobe ao nível arquitetural. Apresentamos SOA (Service-Oriented Architecture) com seus princípios fundamentais — loose coupling, statelessness, contratos explícitos, reusabilidade — e sua diferença em relação a microsserviços. A turma decompõe o sistema do projeto em um conjunto de serviços (recommendation, user, catalog, auth, analytics) e desenha a comunicação entre eles.

O fechamento traz os 8 eixos de RNF do Inteli (segurança, desempenho, usabilidade, confiabilidade, manutenibilidade, portabilidade, eficiência, compatibilidade) com critérios mensuráveis para cada um, alimentando a sprint atual.

Objetivos de aprendizagem

OA-1Descrever os princípios fundamentais de SOA e diferenciá-la de microsserviços.
OA-2Decompor o sistema do projeto em serviços com responsabilidades claras.
OA-3Definir contratos de API entre serviços com schema e versionamento.
OA-4Escrever RNFs mensuráveis para cada um dos 8 eixos do framework Inteli.
OA-5Justificar trade-offs arquiteturais (consistência vs. disponibilidade, latência vs. throughput).
OA-6Documentar a arquitetura escolhida com diagrama C4 ou equivalente.

Pré-requisitos

Aulas 1 e 2 concluídas: pipeline do recomendador rodando em Python.
Métrica de sucesso do MVP definida em docs/recomendador/metrica.md.
Familiaridade com REST, JSON e contratos HTTP do módulo 2.

Cronograma do dia

📚 Bloco 1 · Autoestudo

10h00 — 12h00

Estudo individual orientado pelo material da aula 3.

Leitura completa do Material da Aula 3 (SOA, RNFs, contratos).
Listar 5 RNFs reais do MVP do parceiro (com critério mensurável).
Esboçar em papel a decomposição inicial em serviços.
Caderno de bordo: dúvidas sobre SOA vs. microsserviços.

🎓 Bloco 2 · Instrução PE — Aula em metodologia ativa

14h00 — 16h00

Encontro síncrono com o professor especialista.

14h00 — 14h15 · Daily.
14h15 — 16h00 · SOA, decomposição, contratos e 8 eixos de RNF.

🍴 Intervalo · Almoço

12h00 — 14h00

Janela livre.

🛠️ Bloco 3 · Desenvolvimento do projeto

16h00 — 18h00

Janela de trabalho da equipe.

Documentar a decomposição em serviços em docs/arquitetura/soa.md com diagrama C4 nível 2.
Definir contratos de API (OpenAPI ou Markdown) entre os 3 serviços principais.
Preencher matriz dos 8 eixos de RNF em docs/arquitetura/rnf.md.
Justificar 1 trade-off arquitetural relevante em docs/arquitetura/decisoes.md (ADR).
Abrir Merge Request feat(arch): soa e rnf.

Detalhamento da instrução PE (14h00 — 16h00)

14h00
14h15

DailyDaily de abertura

Cada aluno apresenta em 1 minuto: 1 RNF mensurável que vi no autoestudo / minha proposta de decomposição em serviços / dúvida concreta sobre SOA.

14h15
14h35

TalkSOA · Princípios e contraste com microsserviços

Exposição (15 min): loose coupling, statelessness, contracts. SOA é estilo, microsserviços é uma instância radical desse estilo. Demo de 2 arquiteturas reais (Amazon, Netflix) em diagrama.

14h35
15h00

AtivaDecomposição em serviços — workshop

Em equipes: cada equipe redesenha o sistema do parceiro como conjunto de serviços e justifica fronteiras. Apresentação de 2 equipes — debate sobre acoplamento e responsabilidades.

15h00
15h20

CodingContrato de API · OpenAPI

Live coding de um openapi.yaml para o recommendation service (endpoint, schema, versionamento). Equipes replicam para 1 serviço próprio.

15h20
15h40

Ativa8 eixos de RNF — escrita coletiva

Cada eixo é distribuído entre as equipes; cada equipe escreve 1 RNF mensurável e o critério de aceite. Consolidação no quadro com revisão crítica do professor.

15h40
15h55

TalkTrade-offs e ADR

Apresentação rápida do template de Architectural Decision Record. Como justificar consistência vs. disponibilidade no contexto do recomendador.

15h55
16h00

AtivaSíntese

Cada aluno escreve "a aula 3 me ensinou que...". Anuncia-se a entrega: SOA documentada + RNFs + 1 ADR.

Estratégias de metodologia ativa

Workshop de decomposição — equipes redesenham o sistema antes de qualquer teoria sobre SOA "ideal".
Escrita coletiva de RNF — distribuir os 8 eixos cria foco e gera revisão entre equipes.
ADR como contrato — toda decisão arquitetural relevante deixa registro vivo no repositório.

Princípio orientador

RNF sem critério mensurável não é requisito — é desejo. "Sistema deve ser rápido" é desejo; "p99 < 300ms em endpoint X com 100 req/s" é requisito.

Recursos e ferramentas

Categoria	Recurso	Uso
Slides	`slides/slide-lesson-3.html`	Exposição na instrução PE
Material	`materials/lesson-3-material.html`	Autoestudo
Diagrama	C4 Model (draw.io, Structurizr ou Mermaid)	Visualização da arquitetura
Contratos	OpenAPI 3.x	Especificação dos serviços
Documento	`docs/arquitetura/decisoes.md`	ADRs (Architectural Decision Records)

Verificação de aprendizagem

CR-1Defendeu em equipe a decomposição do sistema em serviços com fronteiras justificadas.
CR-2Escreveu pelo menos 1 RNF mensurável dos 8 eixos durante a escrita coletiva.
CR-3Replicou em equipe contrato OpenAPI para 1 serviço com schema e versão.
CR-4Documentou 1 ADR explicando trade-off arquitetural não-óbvio.
CR-5Abriu Merge Request feat(arch): soa e rnf com diagrama C4 + matriz RNF até as 18h00.

Critério mínimo

Aluno que sair às 18h sem diagrama de serviços + RNFs mensuráveis + 1 ADR está em débito técnico para a aula 4.

Conexão com a aula 4

A aula 4 desce para o banco de dados como camada de serviço — stored procedures e functions encapsulando lógica de domínio próxima dos dados.

Os contratos de API definidos hoje vão decidir o que precisa ser procedure vs. consulta direta.
RNFs de desempenho influenciam onde colocar a lógica (banco vs. aplicação).

Para o autoestudo da aula 4

Antes das 10h: ler material da aula 4, instalar PostgreSQL local com extensão para PL/pgSQL e estudar a sintaxe básica de procedures.