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

# Flexibility

> Adapt EventDBX to each bounded context without rewriting aggregates.

EventDBX is intentionally opinionated about append-only storage yet lenient everywhere else. Domains, schema modes, and plugin payload modes form building blocks you can rearrange without touching the core event log.

## Carve up work with domains

Use domains whenever a team, product surface, or environment needs its own truth:

```bash theme={null}
dbx checkout payments-prod --create   # create if missing, then activate
dbx checkout payments-dev --create    # spin up an isolated dev domain
dbx status                            # confirm active domain + config
```

Each domain keeps its own RocksDB store, Merkle trees, replication offsets, and plugin queues. Teams can experiment safely by creating `*-dev` domains that reuse only the schemas they trust.

### Switch domains with `dbx checkout`

`dbx checkout` activates a domain (and can create or delete it) without touching other domains:

* `dbx checkout <name> --create` to spin up a new domain for experiments, CQRS bounded contexts, or per-environment isolation.
* `--delete [--force]` to remove a domain deliberately; use when retiring experiments.
* `--remote <host[:port]> --token <token> [--remote-tenant <tenant>]` to bind a domain to a remote control socket, useful when your write node lives elsewhere.

This keeps iteration friction low—you can hop between domains or point a domain at a remote daemon without rebuilding schemas or replaying history.

## Evolve schemas gradually

Start in a permissive validation mode while schemas evolve, then restart the daemon with a stricter mode once shapes settle (e.g., `dbx start --restrict=strict`).

```bash theme={null}
dbx schema create person
dbx schema field person first_name --type text --required
dbx schema activate person --version <hash>
```

EventDBX never mutates historical payloads. Instead, new columns surface through snapshots and plugins once they appear often enough. Re-snapshotting an aggregate with `dbx aggregate snapshot <aggregate> <id>` lets you adopt the updated shape without replaying the full stream.

## Route only the slices you need

Plugins choose the minimal payload per domain when you run `dbx plugin config <type> … --payload <mode>`. Modes include `all` (default), `event-only`, `state-only`, `schema-only`, `event-and-schema`, and `extensions-only` (clears payload but keeps metadata/extensions). For process plugins, add `--emit-events=false` if you want the worker supervised without enqueuing jobs.

```bash theme={null}
dbx plugin config http billing --endpoint https://billing.internal/hooks --payload state-only
```

Because payloads are set per plugin, you can bolt on new read models without modifying the write path or exposing data they do not need.

## Sample workflow

1. Create an experiment domain (`payments-fx-dev`) for foreign-exchange work.
2. Copy the core schema and relax validation on new FX fields.
3. Attach a log plugin that mirrors only FX aggregates for analysts.
4. Once the feature stabilizes, promote the schema to `payments-prod` and rehydrate downstream stores by replaying the FX events.

This pattern lets you iterate quickly while preserving EventDBX’s guarantees around durability and integrity.