Creating SaaS Monolith with Jumentix
Use this path when you want fast delivery with strong modular boundaries and a clean future migration path.
Responsibility in context
- Owns: Topology guidance for modular monolith SaaS
- Used with: REST/realtime guides, packages hub, backend-template
- Not responsible for: Deep package API reference (see package pages)
Glossary
- Guide — a journey document; follow steps in order before jumping to package API maps.
- Composition root — startup code that wires env → adapters → use-cases.
What it is
Launch a modular monolith with clear service boundaries ready to extract later.
Recommended Strategy
- Start with bounded contexts in Domain Designer.
- Keep each domain isolated through ports/adapters and explicit contracts.
- Expose interfaces via REST and optionally realtime channels.
- Keep infrastructure pluggable through workspace packages (
@jumentix/*).
Why This Works
- Faster first production release.
- Lower operational complexity than early microservices.
- Clear extraction path when scale or team boundaries require service split.
Delivery Blueprint
- Design domain model and contracts (OpenAPI/AsyncAPI).
- Implement domain/use-case/controller flows.
- Run in one deployment unit with PM2-managed processes.
- Add observability and compliance controls.
- Validate quality gates and coverage thresholds before each push.
Target Audience
- Product teams validating new SaaS propositions quickly.
- Engineering teams that need maintainability without over-architecting too early.
Related Docs
- Architecture and Structure
- Backend Template Hub
- Deploy Target and Packaging Matrix
Next steps
Junior checklist (“I can …”)
- I can explain the goal of this guide in one sentence
- I completed the first success path without guessing jargon
- I know the single next docs page to open