diff --git a/src/docs/antora/modules/ROOT/pages/events.adoc b/src/docs/antora/modules/ROOT/pages/events.adoc
index cc908cf6..3d7d1d0f 100644
--- a/src/docs/antora/modules/ROOT/pages/events.adoc
+++ b/src/docs/antora/modules/ROOT/pages/events.adoc
@@ -89,8 +89,8 @@ class OrderManagement(val events: ApplicationEventPublisher, val dependency: Ord
 ----
 ======
 
-Note, how, instead of depending on the other application module's Spring bean, we use Spring's `ApplicationEventPublisher` to publish a domain event, once we have completed the state transitions on the primary aggregate.
-For a more aggregate-driven approach to event publication, see https://docs.spring.io/spring-data/data-commons/docs/current/reference/html/#core.domain-events[Spring Data's application event publication mechanism] for details.
+Note how, instead of depending on the other application module's Spring bean, we use Spring's `ApplicationEventPublisher` to publish a domain event once we have completed the state transitions on the primary aggregate.
+For a more aggregate-driven approach to event publication, see https://docs.spring.io/spring-data/commons/reference/repositories/core-domain-events.html[Spring Data's application event publication mechanism] for details.
 As event publication happens synchronously by default, the transactional semantics of the overall arrangement stay the same as in the example above.
 Both for the good, as we get to a very simple consistency model (either both the status change of the order _and_ the inventory update succeed or none of them does), but also for the bad as more triggered related functionality will widen the transaction boundary and potentially cause the entire transaction to fail, even if the functionality that is causing the error is not crucial.