Repository map

bluetape4k-javers owns JaVers audit and history semantics. It does not replace the application repository that owns current business state. Keeping those responsibilities separate makes recovery questions answerable.

Released architecture

The following architecture is loaded directly from the immutable 0.2.1 release commit. It stays separate from the current README diagram because the Snapshot line has continued to evolve. Select the preview to open the SVG at the same release commit.

Release module	Responsibility	Not its job
javers-core	codecs, JaVers extensions, cache-backed CDO repositories	durable business storage
javers-ddd	JaVers-oriented aggregate save/commit/publish sequence	ecosystem-wide DDD contracts
javers-exposed	JaVers snapshots and commit metadata in SQL	application CRUD repositories
javers-persistence-redis	Lettuce or Redisson snapshot storage	a Kafka-style replay log
javers-persistence-kafka	publish encoded snapshots to Kafka	snapshot queries or relational history
examples/javers-exposed-ddd	executable command/audit/event/projection lesson	a production transaction/outbox design

The application flow normally starts in its own domain repository. AggregateRepository.save() calls the subclass persist, then javers.commit, then eventPublisher.publishAll. The invocation order is fixed, but delivery timing and failure propagation depend on the publisher adapter. The exact order is implemented in AggregateRepository.kt.

For repository fundamentals such as JDBC transaction ownership, use the published bluetape4k-exposed manual. For Redis, Kafka, and Testcontainers foundations, use the bluetape4k-projects manual. This manual covers how those facilities participate in a JaVers audit path.

Release 0.2.1 has no composite CdoSnapshotRepository that automatically writes to Exposed and Redis or couples Kafka with a query repository. Composition is an application responsibility. Read repository composition before adding a second destination.