diff --git a/docs/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation.md b/docs/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation.md
index 25087ac9fc0df..de7b4abede408 100644
--- a/docs/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation.md
+++ b/docs/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation.md
@@ -336,7 +336,7 @@ Finally, it's important to mention that you might sometimes want to propagate ev
 
 As stated, use domain events to explicitly implement side effects of changes within your domain. To use DDD terminology, use domain events to explicitly implement side effects across one or multiple aggregates. Additionally, and for better scalability and less impact on database locks, use eventual consistency between aggregates within the same domain.
 
-The reference app uses [MediatR](https://github.com/jbogard/MediatR) to propagate domain events synchonously across aggregates, within a single transaction. However, you could also use some AMQP implementation like [RabbitMQ](https://www.rabbitmq.com/) or [Azure Service Bus](https://docs.microsoft.com/azure/service-bus-messaging/service-bus-messaging-overview) to propagate domain events asynchronously, using eventual consistency but, as mentioned above, you have to consider the need for compensatory actions in case of failures.
+The reference app uses [MediatR](https://github.com/jbogard/MediatR) to propagate domain events synchronously across aggregates, within a single transaction. However, you could also use some AMQP implementation like [RabbitMQ](https://www.rabbitmq.com/) or [Azure Service Bus](https://docs.microsoft.com/azure/service-bus-messaging/service-bus-messaging-overview) to propagate domain events asynchronously, using eventual consistency but, as mentioned above, you have to consider the need for compensatory actions in case of failures.
 
 ## Additional resources