> ## Documentation Index
> Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What is the Atoti Enterprise Risk Suite architecture?

> How Atoti Enterprise Risk Suite solutions are distributed as Maven starters, structured internally, and customized through properties and the IModelConfigurer API.

This page describes how solutions in the Atoti Enterprise Risk Suite are distributed, how they are structured internally, and how they can be customized.

## How are solutions distributed?

Solutions are distributed as Maven libraries, not as standalone applications. Each cube provides a Spring Boot starter (for example `var-cube-starter` or `pfe-cube-starter`) that auto-configures everything needed to run that solution.

To use a cube, add its starter as a Maven dependency to an existing Atoti Spring Boot application. This automatically enables the cube and pulls in the required Atoti Server dependencies.

See the setup guide for each solution for dependency coordinates.

## How to add a solution to a project

The simplest way is to add the solution's starter as a Maven dependency. This auto-configures the cube, dimensions, measures, and data loading with sensible defaults.

For more advanced use cases, solutions also expose finer-grained modules:

| Module | When to use |
| - | - |
| `starter` | Default choice. Auto-configures everything with Spring Boot. |
| `config` | For direct access to the Spring `@Configuration` classes, for example to selectively import specific configurations. |
| `lib` | For domain logic (tables, dimensions, measures) without any Spring dependency. This is the most granular level. |

## What is the public API?

Only classes in `.api.` packages are part of the public API and are stable across releases. Classes in `.internal.` or `.private_` packages must not be referenced, as they are implementation details that may change without notice.

## What is the ISolutionCube pattern?

Every cube in an Atoti Enterprise Risk solution exposes an `ISolutionCube<T, L, M, P>` interface as a Spring bean. This interface provides type-safe access to:

* `name()`: the cube name as a string
* `databaseModel()`: the tables and joins of the cube, typed as `T`
* `levels()`: dimension level identifiers, typed as `L`
* `measures()`: measure collections, typed as `M`
* `aggregateProviders()`: the names of the partial aggregate providers the solution adds, typed as `P`

For example, the VaR cube in Market Risk (Enterprise Risk) exposes `IVaRCube`, which gives access to `IVaRCubeLevels` and `IVaRCubeMeasures`. Inject this bean to access cube components programmatically without hardcoding string identifiers.

## How are solutions customized?

Solutions support two customization mechanisms.

### Configuration properties

Spring Boot properties control the runtime behavior of each solution. Properties cover feature flags, display currencies, confidence levels, scenario counts, and other runtime settings.
Properties that apply to common data model are nested under `atoti.solution.model.*`. Cube-specific properties are nested under `atoti.solution.model.cubes.<cube-name>.*.`

See the configuration properties reference for each solution for the full list of available properties.

### IModelConfigurer

For customizations beyond what properties offer, implement the `IModelConfigurer` interface in the consuming application. The [solution archetype](../developer-guide/setup-and-start) generates a `ModelConfigurer` class ready for this purpose, described in [How to customize the application](../developer-guide/setup-and-start#how-to-customize-the-application). This is the Atoti Configuration API entry point for structural changes:

* Adding fields to existing tables or creating new tables
* Adding custom dimensions and hierarchies
* Adding custom measures
* Adding new cubes

For the underlying API, see the Atoti Configuration API reference for [database configuration](../../foundry/database) and [cube configuration](../../foundry/cube/overview).

See the developer guide for examples:

* [Customizing the data model](../developer-guide/database/customizing-data-model)

## How do shared tables work?

Common table creation is idempotent: if a table already exists at startup, the existing instance is reused rather than recreated. This allows multiple solutions to start up without conflicting over shared tables.

Each solution adds its own fields to the shared tables. Customizations are strictly additive: no solution removes or modifies fields added by another, so different solutions can extend the same table without conflicting.

Cross-cutting concerns that span tables, joins, and dimensions (such as the Counterparties feature) are encapsulated in feature implementations. Feature flags in the configuration properties control which features are active.

## Related pages

* [Overview](./overview)
* [Database model](../developer-guide/database/database-model)
* [Customizing the data model](../developer-guide/database/customizing-data-model)