For backend developers and software architects
JoinedWorkz lets you define persistence, APIs and controllers in a DSL and generate standard code that lives next to your own business logic – with no hidden runtime, Git-friendly workflows and developers staying in full control of the code.
JoinedWorkz does not try to hide everything behind a proprietary UI. You work with files in your repository and with tools you know: the JoinedWorkz modeling studio for working with the DSL, and generators running in your build.
Textual model files describing entities, relations, APIs and controller endpoints. Stored in Git, diffed and reviewed like source code.
Generators for OpenAPI, Spring Boot and other targets. You can extend existing generators or add your own to reflect project or team-specific needs.
A Maven plugin to run generation as part of your build, so model and generated code stay in sync without extra manual steps.
The exact setup depends on how your organization uses JoinedWorkz, but a typical project looks like this:
Download the JoinedWorkz modeling studio and open the sample workspace. Inspect the example model, the generated code and how both relate to each other.
Check out the project that uses JoinedWorkz. You will typically find a module or directory containing the DSL model, alongside standard source modules.
Open the model in the studio. Look at how entities, APIs and controllers are represented. Changes you make here will be reflected in the generated code when you run the generators.
Use the Maven plugin to trigger generation. Then build and run the project as usual. Generated code appears in dedicated source folders or modules and can be inspected like any other code.
Implement services, domain logic and integrations on top of the generated structure. Your hand-written code remains separate from generated code, with clear extension points.
For details on installing the studio and using the Maven plugin, see the documentation in Resources.
JoinedWorkz targets those parts of the system that are pattern-heavy and strongly shaped by architecture guidelines. It deliberately leaves room for hand-written logic where you need freedom.
Generators encode the patterns that should be the same across projects, so you do not have to re-create them manually each time.
You work in normal source modules, calling into generated components or extending them where needed.
If you ever decide to stop regenerating, the code that already exists keeps working. You can gradually take over more or less of the generated parts as your project evolves.
Because the DSL is textual and generators are deterministic, you can treat model and generated code like regular artifacts in your Git workflow.
Model files live in the repository, so changes appear in commits, pull requests and reviews like any other source file. You can see what entities or APIs were added, changed or removed.
Merges are resolved with standard tools. There is no hidden binary format that breaks when branches diverge.
Depending on your team conventions, you can either:
JoinedWorkz does not enforce a single strategy here – it fits into how your team already handles generated code.
A typical setup uses the JoinedWorkz Maven plugin in the module that contains the model and generated sources. The exact configuration depends on your version and generators, but it looks conceptually like this:
<plugin>
<groupId>org.joinedworkz.cmn</groupId>
<artifactId>cmn-maven-plugin</artifactId>
<version>1.3.71</version>
<executions>
<execution>
<id>generate-from-model</id>
<phase>generate-sources</phase>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
For the exact plugin coordinates, configuration options and available generators, see the Maven section in the documentation.
Developers who enjoy working close to architecture and tooling can go one step further and work on generators themselves, or provide feedback that leads to new versions.
Generators are versioned as Maven modules. You can build custom generators that reflect your team's architecture decisions and reuse them across projects.
This is where JoinedWorkz becomes a force multiplier: instead of copying patterns manually, you encode them once and keep evolving them centrally.
Designing a good generator is a joint effort between architects and experienced developers. Project accompaniment by the creator of JoinedWorkz is recommended, especially for the first generators.
See About & Contact if you want to discuss your setup or contribute ideas.
Install the studio, clone a project that uses JoinedWorkz and see how the model, generated code and your own logic fit together. If you have feedback or ideas for generators, they are very much welcome.