Architecture

For the core library’s design — DatabasePlatform, audit families, SqlCapturingStatementInspector, QueryPlanExplainer, and cross-cutting invariants — see the core architecture reference.

This page covers only the Spring-specific concerns of the integration module.

Design intent

database-audits-core carries no dependency-injection annotations by design, so it can be used in any context. database-audits-spring-boot-integration provides the one piece core deliberately omits: Spring wiring. The entire production surface is a single class, DatabaseAuditTestConfiguration, a @TestConfiguration(proxyBeanMethods = false) that registers every core audit and its collaborators as explicit @Bean methods with constructor injection.

The shared-capturer invariant — Spring wiring

The runtime audits read SQL from a SqlCapturingStatementInspector. The same bean instance must be Hibernate’s StatementInspector and the instance injected into the runtime audit beans. DatabaseAuditTestConfiguration ensures this by creating the capturer as a @Bean and passing the bean object to Hibernate via a HibernatePropertiesCustomizer:

@Bean
HibernatePropertiesCustomizer sqlCaptureHibernatePropertiesCustomizer(
        SqlCapturingStatementInspector inspector) {
    return props -> props.put(JdbcSettings.STATEMENT_INSPECTOR, inspector);
}

Passing the class name (a String) instead of the bean object would cause Hibernate to instantiate a second capturer that it fills but the audits never read.

Keeping beans in sync with core

Each @Bean method in DatabaseAuditTestConfiguration calls a core audit or collaborator constructor directly; there is no component scan. When a core constructor signature changes, or an audit is added or removed, this class must change in lockstep — a compile failure against core is the intended signal.