Apache Causeway draws the web UI from your domain classes at runtime

No controllers, no HTML, just the domain object on the page

Apache Causeway is a framework for rapidly developing domain-driven applications in Java, and it sits on the Spring Boot platform. The core claim in its documentation is that the user interface is generated from the domain classes: the framework automatically generates the UI from the domain classes, and like all web pages, this UI is generated at runtime, directly from the domain object itself. There are no controllers or HTML to write. The intended audience is developers who want to spend their time on entities, domain services and repositories rather than on request handlers and templates, and the project frames the result as suitable for prototyping or production. The underlying idea comes from the naked objects pattern, which the repository lists among its topics. It is a genuinely different bargain from a template or component framework, and the cost of that bargain is that the shape of the screen is decided by the shape of your model, whether you like it or not.

The same metamodel produces the RESTful API and the GraphQL endpoint

The project description says the framework dynamically generates a representation of the domain model as a webapp, GraphQL or RESTful API, which is the part that makes this more than a UI generator. One metamodel, several representations, and the documentation refers to features derived from the Apache Causeway metamodel when it describes what permissions can be attached to. That shared source of truth is what makes the framework coherent: a property that is visible in the UI is the same property the API exposes, and an action that appears as a button is the same action the API can invoke. The repository layout backs up the breadth, with a viewers directory, an api directory, an extensions directory and a persistence directory sitting alongside core, commons, testing and valuetypes modules. For a team that has to expose a domain to more than one kind of client, that is the argument for the framework. The flip side is that you do not get to hand design the API contract separately from the model, which matters if your API is a product surface in its own right.

SecMan models permissions against features in the metamodel

Authentication is handled by integrating with Spring Security and Keycloak, typically in combination with OAuth2, and those are usually combined with the SecMan module. SecMan provides a set of domain entities that model an authentication model: users, roles and permissions against features derived from the metamodel. That last clause is the interesting design decision. Rather than describing authorisation as a table of URLs, SecMan expresses it in terms of what the domain model exposes, so a permission is attached to a domain feature rather than to a route. The SecMan user is mapped to the authentication principal provided by Spring or Keycloak, which means the identity side can stay with the platform's own mechanisms, and alternatively SecMan can perform its own local authentication. The cost is that permission design becomes a modelling exercise that has to be revisited every time the domain changes, and a team that thinks of authorisation as infrastructure configuration will find the model driven approach slower to start with.

Fixture scripts are prototype seeds and integration test setup at once

Apache Causeway ships features to help you prototype and then fully test an application, and one of them is fixture scripts, which allow pre-canned data to be installed in the running application. The documentation is explicit about the intended reuse: this is great as a starting point for identifying new stories, and later, when the feature is being implemented, the same fixture script can be reused within that feature's integration tests. That double use is the point. A script that seeds a running instance and a script that seeds a test are the same artefact, so the data a developer clicked through during a demo is the data the test asserts against, and drift between the two is much less likely. The repository has testing and regressiontests directories at the top level, and the project lists the integration testing story as a reason the fixture mechanism exists rather than as an afterthought. This is also where the framework earns its keep during a demo, since a stakeholder can see populated screens rather than empty tables.

View models aggregate data, but entities should come first

Most of the time the end user interacts with representations of persistent domain entities, and Causeway also supports view models which can aggregate data from multiple sources. The todoapp example uses a dashboard view model to list todo items not yet done against those completed. So a view model is a screen that is not a table row, assembled from more than one source. The guidance is unusually direct about sequencing: the documentation recommends initially focusing only on domain entities, since that helps drive out a good domain model, and says view models can be introduced later in support of specific use cases. That ordering is a design opinion worth taking seriously. A view model that appears early tends to freeze an early, wrong idea of the domain into a class that everything else references, and the metamodel then treats it as a first class thing. The counterargument is real too: view models are the natural home for the reporting and dashboard screens users always ask for on day two. Causeway allows layout metadata hints to be provided alongside a domain entity, for example to specify the grouping of properties, the positioning of those groups into columns, the association of actions with properties or collections, and the icons on the buttons. This metadata can be specified either as annotations or in JSON form, and the benefit of the JSON form is that it can be updated, and the UI redrawn, without restarting the application. The documentation also notes that any production ready app will require this metadata, while allowing that it can be added gradually on top of the core domain model, in the same spirit as the view model advice. Alongside layout, the framework offers two ways to change data. Properties are editable by default, individual properties can be made non editable, and it is possible to make all properties disabled so that changes happen only through actions. An action can update a single object, several objects, or none at all while performing some other activity, which is how a workflow step is expressed in the same model that renders the buttons.

Starter apps and the module layout tell you where to begin

There is no install command in the project documentation, and the entry point is a repository rather than a package. The documentation points you at the Hello World starter app as the place to start learning, and at the SimpleApp starter app for building your own applications, both hosted under the apache GitHub organisation. The framework itself is a Maven project, with a pom.xml at the root, a parent directory, a bom directory for dependency version management, a gradle directory for the build tooling, and a build-site.sh script for the documentation site, whose sources live under an antora directory. An incubator directory and a retired directory are present at the top level, and the presence of a separate causeway-nightly repository referenced in the badges suggests nightly builds are published outside the main repository. Support comes through a Slack channel and a mailing list linked from the documentation, and the site version in those links is a milestone build, 2.0.0-M9, which is worth noticing before you pin a version.

Where the generated UI becomes the wrong choice

Several cases point away from the framework. The most obvious is a product whose screens are the differentiator and cannot be expressed through property grouping, column layout and action placement, because there is no escape hatch described for writing your own view. The second is an API first project, where the published contract needs its own versioned schema and deprecation policy, since the API here is generated from the same metamodel as the UI and inherits its shape. The third is a team that does not want its domain model to double as a security model, since SecMan ties permissions to features in the metamodel and every model change becomes a security review item. The fourth is organisational: a framework that generates the presentation layer reduces the number of files a new developer must read, but it also means the framework's own configuration becomes part of the application's design surface, and that surface is learned rather than read. The documentation's own advice to add layout metadata gradually is a good model for the whole decision.

Apache-2.0 licensing, a moving main branch and no published releases

The licence field on the repository says Apache-2.0, and the LICENSE file sits at the root, so code you write against the framework is not encumbered by a copyleft obligation. What you do take on is the upgrade path. The repository is not archived, and the last push was on 2026-10-19, so the main branch moves. The repository has no GitHub releases at all, which is the detail that matters for a production team: there is no tagged artifact to pin through your build in the way you would expect from a conventional release cycle, and the documentation links themselves point at milestone versions such as 2.0.0-M9. A STATUS file at the root and a retired directory for modules that have been withdrawn suggest that parts of the framework move through a visible lifecycle rather than disappearing. Practically, that means you should record which commit or milestone your build depends on, and expect to read the diff between milestones rather than a conventional set of release notes when you move forward.

Editorial conclusion

Adopt Apache Causeway when a prototype or a modular monolith has to be demonstrable quickly and the domain model is the part of the system you are confident about, because the framework removes the controller and template layer entirely and gives you fixtures, permissions and layout metadata in one place. Do not adopt it when the screen layout is a product requirement you cannot express in the metamodel, or when you need a hand crafted public API with its own versioning, because the API here is generated from the same model as the UI. Before you commit, walk through the Hello World starter app on your own machine, and check the JSON layout metadata and the SecMan permission model, since those two are where the fine tuning lives.

Frequently asked questions

Official sources

1. apache/causeway on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README