Consistent architecture, by default
Enabled generators apply their persistence, API and controller patterns consistently across projects. Manual code and project-specific extensions remain explicit review concerns.
DSL-based modeling & generation for APIs and backend systems
Keep your architecture consistent.
Generate the boring parts.
JoinedWorkz lets you model persistence, APIs and controllers in a platform-lean DSL. Stable facilities generate specifications and backend code; experimental Quasar support also covers basic UI flows. Your teams keep full control of the business logic.
What is JoinedWorkz?
JoinedWorkz is a modeling and generation toolchain that lets you describe your application’s structure in a domain-specific language. From this model, generators create specifications and code for persistence, APIs, controllers and supporting infrastructure. The experimental Quasar facility can additionally generate basic UI structures. The model is close to the implementation: it uses textual files, lives in Git, and integrates with your usual diff/merge workflow. Generated code can reside in the same repositories as your hand-written logic; clean generation builds update generator-owned output while manual code follows its own lifecycle.
Studio
A standalone modeling studio for defining your DSL models, including transformations to a simple, generator-friendly internal model that does not add extra framework dependencies.
Standard generators
Generators that build on the transformed model. Base, Java and Spring Boot are stable facilities; Quasar is available as an experimental facility.
Maven build integration
A Maven plugin that integrates generation into your build lifecycle. Generators are versioned as Maven modules, so teams can evolve them just like any other dependency.
Typical situations where JoinedWorkz helps
- Architecture guidelines live in Confluence or slide decks, but every project interprets them differently and consistency across teams is hard to enforce.
- Teams repeatedly build similar CRUD-style services and APIs with small variations, spending time on boilerplate instead of focusing on business logic.
- API or interface specifications drift away from the implementation and become hard to keep in sync across services and repositories.
- New developers need a long time to understand how persistence, APIs and integration patterns fit together in a system that has been evolving for years.
JoinedWorkz addresses these situations by moving applicable rules and patterns into generators, so enabled generators apply them consistently to the output they own.
Why architects & managers care
Architecture guidelines in Confluence are only useful if they are applied. JoinedWorkz moves applicable design rules into versioned generators. A clean generation build applies those rules to the output owned by the selected generators.
API-first with real code behind it
Model your APIs first and generate machine-readable specifications and backing components from the same source.
Better onboarding & transparency
New team members start from a model that reflects the current system, not a stale diagram from months ago. After a clean generation build, generator-owned artifacts reflect the model. Manual code and the version running in production remain explicit parts of the project lifecycle.
Cost-efficient standardization
Investing once in a generator makes architecture decisions reusable. Each new project reuses the same generator instead of re-discussing and re-implementing the basics.
Governance without micromanagement
Teams keep autonomy for business logic, while infrastructure, integration patterns and conventions in generator-owned output follow the boundaries encoded in the selected generators.
Why developers can live with it
Developers are rightfully skeptical when tools dictate how code must look. JoinedWorkz is explicit about what it generates – and what stays in your hands.
Plain code, no hidden runtime
Generated output is regular, readable project code, not a black box runtime. Replaceable files are changed through their model, configuration or generator; first-cut and deliberately taken-over files are maintained manually. Whether replaceable output is committed or regenerated is a project decision. See the ownership reference for the exact lifecycle.
No lock-in to the generator
Generated sources are ordinary project code, subject to their normal framework and dependency compatibility. A team can explicitly take over replaceable output before it stops regenerating it; no proprietary JoinedWorkz runtime is required to execute that code.
Textual DSL, Git-friendly
The DSL uses text files that play nicely with Git. Diff, merge and code reviews work with the same tools you already use for your code.
Business logic stays manual
JoinedWorkz generates specifications and selected infrastructure such as persistence, APIs, controllers and integration points. Experimental Quasar support can also generate basic UI structure. The actual business logic remains hand-written and under full control of the team.
In short: JoinedWorkz standardizes the parts that are usually repetitive and architecture-heavy, not the domain-specific logic where teams need freedom.
How it works
1
Model
Use the JoinedWorkz modeling studio to model your domain, persistence, APIs and controllers in a DSL that is focused on your architecture, not tied to a specific platform.
2
Transform & generate
Transform the model into a technology-neutral representation and run the selected facility generators that produce specifications and infrastructure code for the project.
3
Build & evolve
Integrate generation into your Maven build. Treat generators as versioned Maven modules so they can be upgraded deliberately, with their generated-output changes reviewed like other dependency changes.
Consulting, project support & custom generators
JoinedWorkz is typically introduced as part of a project, not as a self-service tool installed in isolation. The real leverage comes from custom generators that encode your architecture guidelines and integration patterns.
JoinedWorkz is developed and supported by JoinedSystems. Project accompaniment can include for example:
- Clarifying goals and choosing a concrete pilot scope (for example one or two services)
- Defining the modeling approach and scope for your first projects
- Designing and implementing custom generators tailored to your standards
- Integrating generation into existing build pipelines and repositories
- Coaching teams on how to work effectively with the model and generated code
- Adjusting generators based on feedback from real projects and evolving architecture guidelines
Ready to explore JoinedWorkz for your organization?
Whether you want to standardize APIs and persistence across teams, experiment with Quasar UI flows or simply reduce the friction around recurring boilerplate – JoinedWorkz gives you a model-driven path that standardizes the essentials while keeping developers in full control.
Developer references: Quickstart · Configuration reference · Maven plugin reference · Generated output and ownership
Not sure yet? - Download the PDF overview