For backend and full-stack developers
JoinedWorkz lets you model persistence, APIs and controllers in a textual DSL and generate specifications and backend structure. Experimental Quasar support also covers basic UI flows. You keep full control over business logic, tests and how you work with Git, builds and frameworks.
Developers are used to tools that overreach: they dictate project layout, hide logic behind frameworks, or introduce lock-in that is hard to undo later. JoinedWorkz explicitly tries to avoid that.
Generated output is readable project code. Replaceable files remain generator-owned; first-cut files become manual after creation. Projects can either commit replaceable output or regenerate it during the build. There is no central runtime that you must rely on at production time.
Generated sources remain ordinary project code, subject to their normal framework and dependency compatibility. Before you stop regenerating replaceable output, make its ownership transition explicit; you can then maintain or migrate it like other manual code.
The DSL is text-based and lives next to your code. Model and manual-source changes use normal diffs; committed generated output can be reviewed in the same pull request. No proprietary project files, no special VCS tooling.
JoinedWorkz generates the boring parts: persistence mappings, repositories, controllers, API contracts and, with the experimental Quasar facility, basic UI navigation. The actual behavior of your system stays hand-written and under your control.
In short: JoinedWorkz standardizes the repetitive, architecture-heavy parts – not the domain-specific logic where your decisions matter most.
JoinedWorkz does not try to replace your framework or IDE. Instead, it adds a few specific artifacts to your repositories and build.
Files such as *.cmn for domain and persistence, profile files for platform mappings
and, where used, UX-related model files for navigation, pages and state.
These files are small and focused. You can edit them in the JoinedWorkz studio or in a text editor.
Stable Base, Java and Spring Boot facilities generate specifications, diagrams and backend sources. The experimental Quasar facility can generate UI routing and simple views.
The output is designed to be readable; its exact structure and style depend on the selected facility and generator version.
Business services and domain logic remain manual. Depending on the facility, JoinedWorkz can also generate configuration, tests or UI scaffolding; their ownership follows the configured outlet. You decide where to put boundaries, how to structure modules and how far you want to go with generation.
As a developer, you usually see JoinedWorkz in a few concrete workflows.
When a project needs another platform or framework, you can implement or extend a facility and its generators. Existing canonical model concepts can be reused where they fit; platform-specific configuration and manual integration may still be required.
This makes support for an additional stack an explicit project or product extension, rather than an implied capability of the shipped facilities.
The experimental Quasar facility can model basic navigation and page structure and generate routing and simple views. You still implement UI components, application shell and state management as needed.
JoinedWorkz is designed to be a thin layer around tools you already use, not a replacement for them.
Models and manual code live in Git. Replaceable generated output can either be committed and reviewed or regenerated during the build, according to project policy. There is no central server that you depend on at development time.
A Maven plugin runs generation as part of your build. Generators are published as Maven modules, so you can pin versions, update them when needed and run builds on CI without extra scripts.
The core model is platform-lean. Generators map it to specific frameworks and stacks. This keeps your model stable even if you swap out parts of your technology stack over time.
The generator controls the structure of certain layers (persistence, APIs, controllers, integration points), but it does not control your domain logic. You can add manual extension points and, if needed, make an explicit ownership transition before taking generated code over.
Replaceable output should be refactored through the model, configuration or generator and then regenerated. First-cut output and deliberately taken-over files are manual code and can be refactored directly. See the ownership reference.
Generators are versioned like any other Maven dependency. You decide when to upgrade. Review committed output diffs or compare a clean regeneration in CI before merging an upgrade.
The DSL is focused on the concepts you already work with: entities, relationships, APIs, parameters, basic UI navigation. Most developers get productive after seeing a few concrete examples.
Yes. Generation runs as part of your builds via Maven. As long as your CI/CD can run your usual builds, it can run the generators too. There is no extra service to deploy.
You can add a custom facility and generators for that stack. This is separate from the publicly supported facilities; reusable model concepts and the generated artifacts depend on that custom implementation.
If your organization is exploring JoinedWorkz, you can usually start hands-on in a small scope without changing your entire way of working.
The goal is not to automate everything from day one, but to relieve you from repetitive work while keeping full visibility and control.
Start with the quickstart to inspect a model and its generated OpenAPI and diagrams. Then use the Spring Boot release example when you want to inspect generated Java and its integration with manually maintained application code.
Developer references: Quickstart · Configuration reference · Maven plugin reference · Generated output and ownership
Not sure yet? - Download the PDF overview
