bluetape4k-javers 0.2 manual
Latest stable Based on Javers release 0.2.1
Object auditing becomes difficult when application state, audit history, and query projections are treated as one store. bluetape4k-javers 0.2.1 gives Kotlin services a JaVers audit layer with Exposed, Redis, and Kafka adapters, but each adapter has a different responsibility. This manual starts with those boundaries so that a service does not accidentally use a cache or stream as its only recoverable record.
Core capabilities
Section titled “Core capabilities”- Audit snapshots and diffs: The audit model explains JaVers commits, snapshots, changes, shadows, and the query semantics built on them.
- DDD aggregate history: javers-ddd and the DDD/CQRS guide connect aggregate commands and domain events to explicit JaVers commits.
- Relational persistence: Exposed persistence stores recoverable CDO snapshots in a JDBC database without replacing the application’s own Exposed repositories.
- Redis and Kafka adapters: Redis supports cache/read-model paths, while Kafka publishes audit records for downstream consumers; neither silently becomes the business source of truth.
- Failure and observability contracts: Failure contracts and observability define partial-write, retry, lag, and recovery signals.
- Runnable learning and comparison: The Exposed DDD example and JaVers/Exposed DDD/Envers comparison connect the abstractions to code and measured evidence.
The manual is pinned to release 0.2.1 (bffe19439ca891fa5301a76421bdef7ba75252a0). Ktor integration, Spring Boot 4 auto-configuration and examples, and the dedicated Gradle benchmark module were added after that release. They are not 0.2 features.
Release overview
Section titled “Release overview”This repository overview is loaded directly from the immutable 0.2.1 release commit. It shows only the structure available to users of this manual; newer Snapshot modules and relationships are intentionally excluded. Select the preview to open the SVG at the same release commit.
Learning map
Section titled “Learning map”
Start here
Section titled “Start here”- Getting started installs a coherent ecosystem dependency set and creates a small Exposed-backed JaVers instance.
- Repository map shows which module owns audit semantics, persistence, and event publication.
- Persistence selection compares Exposed, Redis, and Kafka by recovery and query needs.
- Learning path orders the material for application developers, library integrators, and operators.
Use the manual by question
Section titled “Use the manual by question”If you need to understand JaVers data, read the audit model. If you are composing storage, cache, or publication paths, read repository composition and failure contracts. For a command-to-projection example, follow DDD and CQRS. For production proof, use testing and observability.
Architecture, persistence, and operations
Section titled “Architecture, persistence, and operations”- Audit model separates commits, snapshots, changes, and shadows.
- Repository composition explains the source-of-truth and adapter boundaries.
- Persistence selection compares the recovery contract of Exposed, Redis, and Kafka.
- Exposed, Redis, and Kafka document each adapter in depth.
- Failure contracts and observability turn those boundaries into operational checks.
Modules and runnable material
Section titled “Modules and runnable material”- Foundation: Javers BOM, javers-core, and javers-ddd
- Persistence: javers-exposed, javers-persistence-redis, and javers-persistence-kafka
- Example: JaVers + Exposed DDD order flow
- Benchmarks: how to read the evidence and the JaVers, Exposed DDD, and Envers comparison
- Ecosystem path: where this repository connects to Exposed and application architecture
The release source is the behavior authority. The most important starting points are CdoSnapshotRepository, AggregateRepository, and the javers-exposed-ddd example.