Use cases

Start with the product you need now

Every blueprint now reads like a zero-to-first-MVP path: choose the first product behavior, model the domain slice, expose one usable interface, prove it, then evolve without rewriting the architecture.

Blueprint catalog

Pick the entry point that matches the product risk

The blueprints are not separate templates. They are different topologies over the same domain, contract, adapter, and governance model.

REST API

Ship OpenAPI 3.1 services with interchangeable native HTTP adapters.

Explore the blueprint

Realtime API

Run Socket.IO or gRPC beside a REST fallback and AsyncAPI documentation.

Explore the blueprint

Modular SaaS

Launch one deployable with domain boundaries ready to become services.

Explore the blueprint

Microservices

Keep service communication contract-based with the Message Mediator.

Explore the blueprint

SPA and offline PWA

Build frontend products that share generated SDKs and work offline.

Explore the blueprint

Zero to first MVP

Every use case is a launch path, not just an architecture label

The use cases now describe the smallest product slice a team can ship first: what to model, which interface to expose, which Jumentix packages to use, what to validate, and what evidence proves the MVP is ready.

1bounded context to start

1primary interface for the first user flow

4MVP gates: model, contract, runtime, evidence

5launch paths from the same architecture

Model one slice

Start with one bounded context, two or three entities, the first command, and the user-visible outcome the MVP must prove.

Day 0

Expose one workflow

Choose REST, realtime, modular SaaS, microservice, or SPA/PWA based on the first interaction the product must make usable.

First usable path

Use replaceable adapters

Run in-memory or local infrastructure first, then swap database, broker, function, PM2, or cloud adapters without rewriting use-cases.

No lock-in for the MVP

Ship with proof

Treat route checks, docs sync, focused tests, architecture boundaries, and prepublish evidence as part of the MVP definition.

Ready to demo

MVP stage	Product question	Jumentix action	Ready evidence
Frame	What is the one behavior the first customer must complete?	Capture the bounded context, entities, command, query and owner in Service Management.	A reviewable domain slice with acceptance criteria.
Build	Which interface makes that behavior usable fastest?	Generate or compose the chosen contract, controller/use-case path, SDK/client, and in-memory adapter.	One complete happy path running locally.
Prove	Can the team trust the MVP enough to demo or pilot it?	Run focused tests, route checks, docs sync, architecture boundaries, and website/package gates.	Evidence that behavior, docs and architecture agree.
Evolve	What changes after the first user feedback?	Swap adapters, add events, introduce workers, or extract a service while preserving contracts.	A next increment that does not rewrite the MVP.

Demo-ready checklist

One happy path running locally that a first user can complete without help.
One published contract — OpenAPI, AsyncAPI, or message contract — that matches the running behavior.
One real consumer calling the MVP: a frontend, an SDK client, or an integration script.
Green focused tests, route checks, docs sync, and architecture boundary gates with captured evidence.
A written next increment that evolves the MVP without rewriting contracts or domain code.

Decision matrix

When to choose each Jumentix path

Start with the smallest topology that proves the product. Jumentix keeps the contracts stable so the architecture can grow without a rewrite.

Path	Use it when	Implementation shape	What to measure
REST API	The product needs predictable CRUD, integrations, admin workflows, or public API documentation.	OpenAPI 3.1, native HTTP adapter, controller, use-case, repository port, SDK client.	Route coverage, validation failures, API latency, SDK adoption.
Realtime API	Users need live collaboration, progress updates, notifications, streaming command results, or bidirectional control.	Socket.IO or gRPC process with REST fallback, AsyncAPI contracts, correlated messages, optional Redis Streams.	Delivery acknowledgement, reconnect behavior, fan-out reliability, fallback parity.
Modular SaaS	You need to ship one product quickly but still protect domain ownership, tenancy, RBAC, and later extraction.	One deployable, feature modules, shared composition root, tenant-aware policies, contract events.	Release frequency, onboarding time, module coupling, cost per environment.
Microservices	Team ownership, scaling profile, data lifecycle, or deployment cadence requires independent services.	Independent workers/services, Message Mediator contracts, broker adapters, per-service gates.	Service autonomy, broker durability, contract compatibility, incident isolation.
SPA/PWA	The frontend must work offline, sync later, or share API contracts across React/Vue products.	Generated SDKs, Cana local store, React/Vue hooks, IndexedDB-ready state flow.	Offline completion rate, sync conflicts, stale reads, UI event latency.

Shared foundation

Every use case keeps the same engineering rules

Contracts before adapters

OpenAPI, AsyncAPI, message contracts, and error contracts describe the boundary before framework code handles it.

Use-cases before infrastructure

Application services depend on ports. Databases, queues, HTTP servers, and cloud providers plug in at composition time.

Evidence before release

Tests, route checks, architectural boundary checks, security review, and docs synchronization are part of delivery.

Build the product. Keep the architecture.

Explore the source, run the factory locally, and turn your next Node.js service into a repeatable platform capability.

Read the docs GitHub