1. Domino Brix
2. App & module structure

App & module structure

A typical Domino Brix app uses a multi-module Maven layout. The structure below mirrors the sample app while keeping everything generic so you can map it to your own project.

Top-level repository layout

The root aggregates backend, frontend, shared, and feature modules under one build.

			@BrixPresenter
public class AdminPresenter extends Presenter<AdminView> {
  @Override
  public Set<String> getRoles() {
    return Set.of("admin");
  }

  @Override
  public Authorizer getAuthorizer() {
    return RolesAllowedAuthorizer.INSTANCE;
  }
}

		

Root aggregator

• The root pom.xml aggregates all top-level modules.
• It centralizes dependency versions and shared build plugins.
• It does not contain production sources.

Main app modules

<app-name>-backend

The backend module is the deployed server artifact (Quarkus or similar).

• Serves the compiled frontend bundle as static resources.
• Hosts backend logic, persistence, and REST endpoints.
• Usually depends on <app-name>-shared for DTOs and events.

<app-name>-frontend

The frontend module boots the GWT/J2CL application.

• Owns the entry point class (for example, App implements EntryPoint).
• Configures Domino Rest, themes, and global UI settings.
• Loads all generated BrixComponentInitializer services.
• Starts the app via Brix.get().start(...) with startup tasks.
• Aggregates all feature frontend and UI modules on the GWT/J2CL classpath.

<app-name>-shared

Shared code used by both backend and frontend.

• DTOs, events, user models, and enums.
• No UI code or GWT-only types.
• Consumed by the backend, app frontend, and features.

Feature modules

Each feature lives under its own folder with a three-module structure.

			SecurityContext sc = (SecurityContext) Brix.get().getCoreComponent().core().getSecurityContext();
sc.setUser(new MyUser());
sc.setUnauthorizedAccessHandler(() -> window.alert("Access denied"));

		

<feature-x>-frontend

Presenter logic and routing live here.

• @BrixPresenter classes, routing, and presenter state handling.
• View interfaces and UI handler contracts.
• Feature startup tasks and event listeners.
• Generated *Impl presenters and routing classes.

<feature-x>-ui

Concrete views and wiring are implemented here.

• @UiView classes with Domino UI widgets and layouts.
• Dagger component/module wiring between presenters and views.
• @BrixComponent classes that register the feature.
• Generated *_UiView classes and initializer services.

<feature-x>-shared

Shared types between feature frontend and UI.

• DTOs, request/response models, and event payloads.
• Contracts, constants, and utilities without UI dependencies.

How the pieces fit together

• The app frontend bootstraps the UI and loads all BrixComponentInitializer services.
• Feature UI modules contribute component initializers and view implementations.
• Feature frontend modules contribute presenters, routes, and startup tasks.
• The app frontend aggregates all features on the GWT/J2CL classpath into one bundle.
• The backend serves the compiled bundle and exposes REST endpoints.

Dependency overview

A simplified dependency view keeps shared code flowing into backend and frontend while features stay modular.

			public class DepartmentAuthorizer implements Authorizer {
  @Override
  public boolean isAuthorized(IsSecurityContext context, HasRoles hasRoles) {
    return context.isAuthenticated()
        && context.getUser().getAttributes().get("department").ifTypeIs(String.class, dept -> {
             return dept.equals("engineering");
           });
  }
}

		

Entry point responsibilities

• Load all component initializers via BrixComponentInitializer_ServiceLoader.load().
• Initialize themes and UI frameworks.
• Configure Domino Rest default service root.
• Fetch config, then call Brix.get().init(...) and Brix.get().start(...).
• Optionally set the router root path and fire the current history state.

Build outputs

• The frontend build produces a compiled GWT/J2CL bundle for the backend.
• The backend packages the final server artifact with static assets.

Naming guidance

• Keep module names consistent: <app-name>-backend, <app-name>-frontend, <app-name>-shared.
• For features, use <feature>-frontend, <feature>-ui, <feature>-shared under a feature aggregator.
• Align Java package structure with module responsibilities.