Emissão de NF-e e Controle de Estoque

Visão geral

Sistema distribuído de faturamento interno inspirado no domínio de emissão de NF-e. Cobre cadastro de produtos, criação e fechamento de notas, reserva assíncrona de estoque e geração de PDF após a solicitação de impressão.

Importante: este projeto não é um emissor fiscal oficial. Não há integração com a SEFAZ, XML fiscal oficial, certificado A1/A3 ou regras tributárias reais. O domínio correto é "faturamento interno inspirado em NF-e" — o foco é arquitetura, integração assíncrona, cloud e qualidade de engenharia.

Arquitetura

Sistema distribuído serverless com contextos de faturamento e estoque, inspirado em microservices e event-driven architecture, mas com persistência compartilhada no DynamoDB.

• servico-estoque (.NET 8) Clean Architecture enxuta: Api, Aplicacao, Dominio e Infraestrutura. Entidade Produto com DebitarEstoque().
• servico-faturamento (Go) Lambdas de faturamento e geração de PDF. Entidade NotaFiscal com Fechar().
• web-app (Angular) Frontend integrado ao Cognito, propagando JWT e X-Correlation-Id.
• infra/cdk EventBridge, SQS, DLQ, DynamoDB, CloudFront, alarmes, dashboard e X-Ray.

Fluxo de fechamento de nota e reserva de estoque

1. O usuário autentica via Cognito no frontend Angular, que passa a enviar JWT e X-Correlation-Id.
2. O usuário cadastra produtos no serviço de estoque (.NET) e cria uma nota no serviço de faturamento (Go).
3. Ao fechar a nota, o faturamento atualiza o status e grava o evento Faturamento.NotaFechada usando TransactWriteItems — nota e evento na mesma transação.
4. Uma regra do EventBridge encaminha o evento para a fila SQS de reserva.
5. O consumer de estoque em Go lê a nota, reserva saldo no DynamoDB e publica ReservaConfirmada ou ReservaFalhou.
6. O faturamento consome a confirmação e atualiza a nota para RESERVADA ou CANCELADA.
7. Na impressão, a API exige Idempotency-Key; a Lambda de PDF gera o arquivo, salva no S3 e a solicitação passa para CONCLUIDA.

Pontos fortes

• Event-driven implementado de verdade: EventBridge, SQS e DLQ provisionados no CDK e usados em código executável.
• Outbox publisher em .NET usando DynamoDB Streams — um diferencial técnico incomum.
• DynamoDB com single-table design e GSIs, raro em portfólios júnior.
• Propagação de correlation-id entre frontend, APIs e eventos.
• Observabilidade provisionada: logs estruturados, alarmes, dashboard e X-Ray.
• Sistema poliglota, com o serviço .NET demonstrando Clean Architecture aplicada.

Limites e decisões conscientes

O que este projeto não faz, e por quê. Descrever isso com precisão vale mais do que exagerar o escopo.

• Estoque e faturamento compartilham a mesma tabela principal no DynamoDB, o que reduz a autonomia dos contextos — não são microservices puros.
• A atomicidade do outbox não é uniforme: FecharNota() usa transação, mas CriarSolicitacaoImpressao() e ReservarEstoqueHandler gravam em operações separadas.
• O CDK ainda instancia uma NetworkStack com VPC e recursos pensados para ECS/RDS, herdados de uma arquitetura anterior, mesmo com as Lambdas rodando fora da VPC.
• Convivem artefatos da trilha ativa serverless e de uma fase antiga com PostgreSQL, RabbitMQ e Docker Compose, o que reduz a clareza do repositório.