Interpretando uma arquitetura

Em construção

Esta página está em construção. O conteúdo pode mudar ou estar incompleto.

O cenário

Contexto

Uma empresa regulada precisa entregar ao comitê de mudanças a análise de impacto antes de alterar o payload de um evento.

O que acontece

Sem ASL o agente lê um diagrama desenhado para a última auditoria e ainda precisa ler o código de cada serviço para confirmar.

Como a ASL ajuda?

Com ASL, ele lê a arquitetura do sistema. A empresa sincroniza os manifestos da ASL a cada mudança no CI/CD, então a análise reflete o estado atual e pode ser rastreada como evidência.

Hoje: Markdown como harness

agent

> O comitê de mudanças precisa da análise de impacto para alterar o payload do payment-events.

● Read(architecture-review-q1.drawio)

⎿ architecture-review-q1.drawio · vários KB de XML, setas sem tipo

<mxCell id="9" value="tokenizer" style="rounded=1;fillColor=#dae8fc;" vertex="1" parent="1">
<mxCell id="14" style="endArrow=classic;html=1;" edge="1" parent="1" source="9" target="12"/>
<mxCell id="12" value="ledger-service" style="rounded=1;fillColor=#d5e8d4;" vertex="1" parent="1">

● O diagrama mostra tokenizer → ledger-service, desenhado para a revisão do Q1. Ele não diz se a seta é um evento ou uma chamada, e tem 8 meses. Para ter certeza eu teria que ler o código de cada serviço. Impacto provisório: ledger-service.

Uma análise com lacunas: o fraud-scoring entrou depois do diagrama. O comitê não aprova o que não consegue rastrear.

Arquitetura como Código com ASL

agent

> O comitê de mudanças precisa da análise de impacto para alterar o payload do payment-events.

● Read(architecture/payments.asl.yaml)

⎿ ~2,6 KB de YAML, relações tipadas

- from: {kind: Application, name: tokenizer}
  to: {kind: Topic, name: payment-events}
  type: produces
- from: {kind: Application, name: ledger-service}
  to: {kind: Topic, name: payment-events}
  type: consumes
- from: {kind: Application, name: fraud-scoring}
  to: {kind: Topic, name: payment-events}
  type: consumes

● payment-events é produzido pelo tokenizer e consumido por ledger-service (team-ledger) e fraud-scoring (team-risk). Ele carrega tokens, não dados de cartão: nada com pci o toca, então não precisa de revisão PCI. A empresa sincroniza os manifestos da ASL a cada mudança no CI/CD, então este é o estado atual.

Uma análise que o comitê rastreia até os manifestos.