Casos de uso

Comece com o produto de que você precisa agora

Cada blueprint agora funciona como uma jornada do zero ao primeiro MVP: escolha o primeiro comportamento de produto, modele a fatia de domínio, exponha uma interface usável, comprove e evolua sem reescrever a arquitetura.

Catálogo de blueprints

Escolha o ponto de entrada que combina com o risco do produto

Os blueprints não são templates separados. Eles são topologias diferentes sobre o mesmo modelo de domínio, contratos, adaptadores e governança.

API REST

Entregue serviços OpenAPI 3.1 com adaptadores HTTP nativos intercambiáveis.

Explore o blueprint

API em tempo real

Execute Socket.IO ou gRPC ao lado de fallback REST e documentação AsyncAPI.

Explore o blueprint

SaaS modular

Lance um deploy com limites de domínio prontos para virar serviços.

Explore o blueprint

Microsserviços

Mantenha a comunicação entre serviços baseada em contratos com o Message Mediator.

Explore o blueprint

SPA e PWA offline

Crie produtos frontend que compartilham SDKs gerados e funcionam offline.

Explore o blueprint

Do zero ao primeiro MVP

Todo caso de uso é uma jornada de lançamento, não só um rótulo arquitetural

Os casos de uso agora descrevem a menor fatia de produto que um time pode publicar primeiro: o que modelar, qual interface expor, quais pacotes Jumentix usar, o que validar e qual evidência prova que o MVP está pronto.

1contexto delimitado inicial

1interface primária para o primeiro fluxo

4gates MVP: modelo, contrato, runtime, evidência

5jornadas de lançamento na mesma arquitetura

Modele uma fatia

Comece com um contexto delimitado, duas ou três entidades, o primeiro comando e o resultado visível que o MVP precisa provar.

Dia 0

Exponha um fluxo

Escolha REST, realtime, SaaS modular, microsserviço ou SPA/PWA conforme a primeira interação que o produto precisa tornar utilizável.

Primeiro caminho usável

Use adaptadores substituíveis

Rode primeiro com infraestrutura in-memory ou local, depois troque banco, broker, function, PM2 ou cloud adapters sem reescrever casos de uso.

MVP sem lock-in

Publique com prova

Trate checks de rota, sync de docs, testes focados, limites arquiteturais e evidência prepublish como parte da definição do MVP.

Pronto para demo

Etapa do MVP	Pergunta de produto	Ação no Jumentix	Evidência de pronto
Enquadrar	Qual é o comportamento que o primeiro cliente precisa concluir?	Capture contexto delimitado, entidades, comando, query e owner no Service Management.	Uma fatia de domínio revisável com critérios de aceite.
Construir	Qual interface torna esse comportamento utilizável mais rápido?	Gere ou componha o contrato escolhido, caminho controller/use-case, SDK/client e adaptador in-memory.	Um happy path completo rodando localmente.
Provar	O time pode confiar no MVP para demo ou piloto?	Rode testes focados, checks de rota, sync de docs, limites arquiteturais e gates de website/pacote.	Evidência de que comportamento, docs e arquitetura concordam.
Evoluir	O que muda após o primeiro feedback de usuário?	Troque adaptadores, adicione eventos, introduza workers ou extraia um serviço preservando contratos.	Um próximo incremento que não reescreve o MVP.

Checklist de pronto para demo

Um happy path rodando localmente que o primeiro usuário conclui sem ajuda.
Um contrato publicado — OpenAPI, AsyncAPI ou contrato de mensagem — que corresponde ao comportamento em execução.
Um consumidor real chamando o MVP: um frontend, um client SDK ou um script de integração.
Testes focados, checks de rota, sync de docs e gates de limites arquiteturais verdes com evidência capturada.
Um próximo incremento escrito que evolui o MVP sem reescrever contratos ou código de domínio.

Matriz de decisão

Quando escolher cada caminho Jumentix

Comece com a menor topologia que prova o produto. O Jumentix mantém contratos estáveis para a arquitetura crescer sem reescrita.

Caminho	Use quando	Formato de implementação	O que medir
API REST	O produto precisa de CRUD previsível, integrações, fluxos administrativos ou documentação pública de API.	OpenAPI 3.1, adaptador HTTP nativo, controller, caso de uso, port de repository, SDK cliente.	Cobertura de rotas, falhas de validação, latência da API, adoção do SDK.
API realtime	Usuários precisam de colaboração ao vivo, progresso, notificações, resultados de comando em streaming ou controle bidirecional.	Processo Socket.IO ou gRPC com fallback REST, contratos AsyncAPI, mensagens correlacionadas, Redis Streams opcional.	Acknowledgement de entrega, reconexão, confiabilidade de fan-out, paridade do fallback.
SaaS modular	Você precisa lançar um produto rápido, preservando domínio, tenancy, RBAC e extração futura.	Um deploy, módulos por feature, composition root compartilhada, políticas tenant-aware, eventos contratados.	Frequência de release, tempo de onboarding, acoplamento entre módulos, custo por ambiente.
Microsserviços	Ownership de times, perfil de escala, ciclo de vida dos dados ou cadência de deploy exigem serviços independentes.	Workers/serviços independentes, contratos do Message Mediator, adaptadores de broker, gates por serviço.	Autonomia de serviço, durabilidade do broker, compatibilidade contratual, isolamento de incidentes.
SPA/PWA	O frontend precisa funcionar offline, sincronizar depois ou compartilhar contratos de API entre produtos React/Vue.	SDKs gerados, store local Cana, hooks React/Vue, fluxo de estado pronto para IndexedDB.	Taxa de conclusão offline, conflitos de sync, leituras antigas, latência de eventos da UI.

Fundação compartilhada

Todo caso de uso mantém as mesmas regras de engenharia

Contratos antes de adaptadores

OpenAPI, AsyncAPI, contratos de mensagem e contratos de erro descrevem o limite antes do código de framework tratá-lo.

Casos de uso antes da infraestrutura

Serviços de aplicação dependem de ports. Bancos, filas, servidores HTTP e provedores cloud entram no momento de composição.

Evidência antes do release

Testes, checagens de rota, limites arquiteturais, revisão de segurança e sincronização de docs fazem parte da entrega.

Construa o produto. Preserve a arquitetura.

Explore o código, execute a fábrica localmente e transforme seu próximo serviço Node.js em uma capacidade repetível de plataforma.

Leia a documentação GitHub