From 1c93a2440ac36e59bcc81fe2de7fdefb0fdd7969 Mon Sep 17 00:00:00 2001
From: sant0s <919197+sant0s@users.noreply.github.com>
Date: Mon, 20 Jul 2026 13:35:11 +0100
Subject: [PATCH] Update events.adoc

Simplify text.

Signed-off-by: sant0s <919197+sant0s@users.noreply.github.com>
---
 src/docs/antora/modules/ROOT/pages/events.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/docs/antora/modules/ROOT/pages/events.adoc b/src/docs/antora/modules/ROOT/pages/events.adoc
index 826d8502e..de7ae235e 100644
--- a/src/docs/antora/modules/ROOT/pages/events.adoc
+++ b/src/docs/antora/modules/ROOT/pages/events.adoc
@@ -46,7 +46,7 @@ class OrderManagement(val inventory: InventoryManagement) {
 ======
 
 The `complete(…)` method creates functional gravity in the sense that it attracts related functionality and thus interaction with Spring beans defined in other application modules.
-This especially makes the component harder to test as we need to have instances available of those depended on beans just to create an instance of `OrderManagement` (see xref:testing.adoc#efferent-dependencies[Dealing with Efferent Dependencies]).
+This especially makes the component harder to test as we need to have instances available of those dependent beans just to create an instance of `OrderManagement` (see xref:testing.adoc#efferent-dependencies[Dealing with Efferent Dependencies]).
 It also means that we will have to touch the class whenever we would like to integrate further functionality with the business event order completion.
 
 We can change the application module interaction as follows: