Música ao vivo
mixart
QR na mesa do bar: a plateia pede a música e paga a gorjeta por PIX, sem baixar app
- Cliente
- Produto próprio da CG Mixart
- Categoria
- Marketplace multi-lado com pagamentos
- Período
- fev–ago 2026
- Estado
- Em produção
O problema
O músico que toca ao vivo fecha por cachê fixo e não captura a disposição de pagar da plateia no momento exato em que ela existe: o pedido vira grito ou guardanapo, e a gorjeta, quando vem, é dinheiro vivo que ninguém rastreia. Do outro lado do balcão, bar e produtor contratam por indicação de grupo de WhatsApp, sem contrato e sem garantia de que o músico aparece. Repertório, gorjeta, contrato e garantia do pagamento viviam em quatro lugares diferentes, nenhum deles no mesmo aplicativo.
O que foi construído
QR code na mesa: o cliente abre o repertório numa Flutter Web, pede a música e paga a gorjeta por PIX sem instalar nada e sem criar conta, enquanto o músico vê o pedido entrar na fila. A mesma base (identidade, carteira com escrow, contrato digital, radar geolocalizado, avaliações) sustenta o mixart Delivery: contratação de prestador musical com escrow dividido, início de serviço liberado só a 10 metros do contratante (Haversine conferida no servidor) e contrato de 18 cláusulas. O backend é .NET 9 em DDD porque comissão por plano, divisão do escrow e as transições entre 15 status são invariantes de dinheiro, não validação de formulário.
Decisões de engenharia
Strangler fig: 16 bounded contexts sobre o monolito
O monolito seguiu atendendo produção enquanto 16 projetos de bounded context assumiram o domínio por baixo, ligados por 21 ACL adapters que traduzem tipo legado em agregado. Treze já têm as três camadas, com MusicTalks e Delivery na frente; Communication, Music e Social ainda são casca de Domain + Infrastructure. Nenhum controller do monolito precisou ser reescrito de uma vez.
ls -d music_system/backend/src/*/ | grep -v SharedKernel | wc -l → 16; ls music_system/backend/MusicSystem.Backend/AntiCorruption/*.cs | wc -l → 21; contagem de .cs por contexto: MusicTalks 211, Delivery 116, Financial 50, LiveStreaming 45, Orchestration 35, Identity 33, Ticketing 32
Cardápio no QR: pedido e gorjeta sem login
O cliente escaneia o QR da mesa e cai numa Flutter Web que gera um clientToken anônimo (UUID v4 persistido no navegador): pede a música, paga a gorjeta, acompanha "Meus Pedidos" e contesta se a música não tocou, tudo sem cadastro. Os endpoints são [AllowAnonymous], mas passam por rate limit de IP+token, sanitização de texto e bloqueio de menor pela claim age_tier antes de aceitar qualquer dinheiro. São quatro modos de cobrança configuráveis pelo músico no mesmo fluxo: PIX direto na chave dele, carteira via Asaas, pré-aprovação e termo de risco.
music_system/lib/core/services/client_token_service.dart (_uuid.v4() em SharedPreferences); Controllers/SongRequestController.cs: 1.280 linhas, 13 [AllowAnonymous], TryAcquireUnlockSlot(ip, clientToken, musicianId) → 429, InputValidators.SanitizePlainText, ReadPediuTocouModeAsync ("pediu_tocou_mode (4 modos)")
Escrow em dois baldes, transporte irrevogável
O valor pago no Delivery vira ServiceEscrow e TransportEscrow, liberáveis de forma independente: cancelar nunca reduz o transporte, porque o prestador já queimou o combustível. A comissão por plano (10% Free, 7% Pro, 5% Premium) incide só sobre o serviço, e as transições dos 15 status vivem numa tabela de destinos permitidos em vez de ifs espalhados pelo agregado. Cada regra cita no código o ID do requisito que a originou: 21 IDs distintos que ligam a linha de C# à decisão de negócio.
src/Delivery/.../Aggregates/DeliveryRequest.cs:216 "CRITICAL MONEY-09: TransportEscrow is NOT modified here. Transporte irrevogavel"; AllowedTransitions.cs (82 linhas); ValueObjects/CommissionRate.cs (0.10m / 0.07m / 0.05m) usada em ReleaseServiceEscrowCommandHandler; DeliveryStatus.cs → 15 valores; grep -rhoE '(COMP|MONEY|PROV|DISP|CONT|MATCH)-[0-9]{2}' src/Delivery | sort -u | wc -l → 21
Webhook de pagamento idempotente com fila de retry
Gateway reentrega evento, e reentrega mal tratada credita duas vezes. A dedup é global na collection processed_webhooks, com o id do evento como _id (unicidade nativa do Mongo, não checagem em memória) e TTL de 30 dias. O que falha cai numa fila com payload, AttemptCount e NextRetryAt, backoff de 10min×(N+1), e vira permanent_failure na quinta tentativa, para tratamento manual.
Services/WebhookIdempotencyService.cs (GetCollection("processed_webhooks"), ExpireAfter = TimeSpan.FromDays(30)); Services/FailedWebhookService.cs (nextDelay = TimeSpan.FromMinutes(10 * (newAttempt + 1)); newAttempt >= 5 ? "permanent_failure" : "pending")
Stack
Telas
O papel da CG Mixart
Arquitetura e execução ponta a ponta: domínio DDD em .NET 9 com CQRS, app Flutter mobile e web, painéis Angular 21, infra Docker/Nginx em Oracle Cloud e as integrações de PIX com escrow próprio. A identidade visual veio do brandguide da agência CADMO. A CG Mixart implementou o design system, não o desenhou.
Ressalvas e notas técnicas, verificadas no códigoabrir
Ressalvas verificadas no código, todas em 28/08/2026: • Um modo de cobrança no ar, não quatro: o backend continua suportando os quatro modos do Pediu Tocou (PIX direto na chave do músico, Carteira via Asaas, pré-aprovação e PIX com termo de risco; Models/UserProfile.cs, campo pediu_tocou_mode), mas desde 2026-05-28 o painel do músico expõe só a Carteira. Os outros três estão comentados no seletor de tocando_agora_sheet.dart, com o bloco preservado para reativar. Por isso os "4 modos" não viraram métrica. • Verificação ponta a ponta desligada: os testes de integração estão marcados com skip porque dependem de estado deslogado e de popup do Google. Na prática, o fluxo completo não é validado automaticamente hoje. • Domínio novo ainda incompleto: os contextos de Communication, Music e Social são casca: têm Domain e Infrastructure, sem a camada de aplicação. Orchestration é o único contexto sem verificação própria. • Schema novo ainda não desceu: todas as migrations EF pertencem ao AppDbContext do monolito; IdentityDbContext e TicketingDbContext não têm nenhuma (find music_system/backend/src -path '*Migrations*' -name '*.cs' não retorna nada), ou seja, as tabelas dos contextos novos ainda não existem no Postgres. • iOS não publicado sob a marca: o applicationId Android é br.com.cgmixart.app (android/app/build.gradle.kts:35), mas o bundle iOS segue com o valor de scaffold com.musicapp.musicSystem no Runner.xcodeproj. Existem submit_appstore_prod.py e código de Apple billing, e ainda assim não há app na App Store sob esse ID. • Firestore residual com regra aberta: o app Flutter saiu do Firestore (não há cloud_firestore no pubspec.yaml e disableFirestoreDualWrite está em true em core/config/feature_flags.dart:28); ele sobrevive só como CMS da landing Angular. O music_system/firestore.rules deployado, porém, é da era anterior e ainda tem allow read: if true em users, posts, stories, works e services, mais escrita aberta em /requests. Dívida de segurança conhecida e não fechada. • Fase 5 do Delivery desligada: disputa, anti-sabotagem e auto-release de escrow estão com kPhase5Enabled = false em features/delivery/domain/value_objects/phase5_flags.dart, e as telas de cancelamento e hora extra checam essa flag antes de aparecer. A multa de cancelamento vai junto: CancelDeliveryRequestCommandHandler.cs:38-40 grava CancellationPenalty.None fixo, sob o comentário "Phase 5 will implement real penalty calculation logic". Por isso a multa foi retirada do texto da solução nesta revisão. O milestone base foi entregue em 2026-04-09 (v1.0.337); a versão atual do pubspec é 1.0.927. • Tradução desigual: dos cinco idiomas selecionáveis, o pt-PT é override parcial sobre o pt-BR. Onde falta tradução, cai no português do Brasil (fallback declarado no próprio locale_service.dart e no slang.yaml). • Painéis Angular são dois apps, não um: front_BI e mixart-landing são bases separadas. O Tailwind v4 está só na landing e o ECharts 6 só no BI. • Documentação interna atrasada: o CLAUDE.md do repositório descreve uma arquitetura menor do que a que está no código. Tudo que esta ficha afirma foi lido no código, nunca no documento. • Autoria: boa parte do código foi escrita em par com assistente de IA, o que está registrado no histórico do repositório. É mais uma razão para o volume de código ficar fora das métricas: ele mediria a ferramenta, não a entrega. • Nenhuma métrica de negócio (usuários ativos, receita, uptime) aparece aqui porque o repositório não prova nenhuma.
Quem faz
Construída de artistas para artistas.
O mixart nasce dessa complementaridade: quem entende a dor real do músico encontra quem sabe integrar sistemas complexos.
Carlos
Fundador e desenvolvedor principal
Programador há mais de quinze anos e dono de loja de instrumentos. Deu aula de violão, guitarra e teclado por seis anos, vendeu cordas, teclas e sopro por mais de uma década e, em 2021, passou a escrever os sistemas que o varejo usava: PDV, PDO e ERP. Hoje dirige a Centro Musical, em São José dos Pinhais, e é o desenvolvedor principal do mixart, que fundou em 2024. O balcão é onde ouviu, todo dia e por anos, as dores que o produto resolve.
- Aula de música desde 2004
- Varejo desde 2010
- Sistemas desde 2021
- mixart em 2024
Gilmar
Arquitetura, negócio e parcerias
Programador de TI com formação em sistemas integrados de grande porte, os ERPs Protheus e SAP. Desenhou a arquitetura de fluxo, as regras de negócio e o ecossistema inteiro do mixart. Lidera a parte comercial e a relação com parceiros.
- ERPs de grande porte
- Arquitetura de fluxo
- Regras de negócio
- Comercial e parcerias
PDF · 20 páginas · 7,7 MB