link

content/blog/react-testing-strategy/index.en.md

@@ -128,4 +128,4 @@ How can we apply what I explained in the previous section to an application that
 
 Lastly, coupling will prevent you from easily testing your code. The solution to avoid this kind of problem is to apply the Dependency Inversion Principle from the SOLID principles. It will help you make your code more modular and easy to test. I’ve written a blog post to explain how to apply it to a React application:
 
-{{< page-link page="/how-to-reduce-coupling-in-your-react-app" >}}
+{{< page-link page="how-to-reduce-coupling-in-your-react-app" >}}

content/blog/repository-design-pattern/index.en.md

@@ -121,7 +121,7 @@ Do the functions 'get, add, and remove' ring a bell? Perhaps, they remind you of
 
 The repository design pattern is ideal for isolating the domain from Input/Output operations. I’ve written an article about hexagonal architecture, an architectural pattern that helps in building sustainable software and ease testing too:
 
-{{< page-link page="/hexagonal-architect-by-example" >}}
+{{< page-link page="hexagonal-architect-by-example" >}}
 
 Depending on business needs, a repository can include various retrieval methods. As I mentioned earlier, a repository is a collection of domain objects. To be more precise, it's a collection of aggregates. An aggregate is a cluster of objects that together represent a domain concept, like the `Map`. In this case, the `Map` object is the aggregate root, and the `Marker` object is an entity that belongs to the `Map` aggregate. Since the aggregate root acts as the entry point for all internal interactions, a repository can only work with an aggregate root.
 

content/blog/solid-dependency-inversion-principle/index.en.md

@@ -99,7 +99,7 @@ By introducing the `ProductRepository` interface and using dependency injection,
 
 Testing chunks of code that interacts with Input/Output (IO) can be challenging, especially when we only want to test the business logic . Now, it is easy to test the product creation because we can replace the mysql repository but a fake one. I’ve written a blog post to explain how the dependency inversion principle can ease testing:
 
-{{< page-link page="/ease-testing-thanks-to-the-dependency-inversion-design-pattern" >}}
+{{< page-link page="ease-testing-thanks-to-the-dependency-inversion-design-pattern" >}}
 
 # Rule 3: An interface should not depend on concrete implementations
 

content/blog/what-is-the-difference-between-cqs-and-cqrs-patterns/index.en.md

@@ -107,6 +107,6 @@ Depending on the number of use cases the service classes can become really huge.
 
 I've written a blog post to explain what is a commands and we can apply it to query too:
 
-{{< page-link page="/command-handler-patterns" >}}
+{{< page-link page="command-handler-patterns" >}}
 
 Thanks to my proofreader [@LaureBrosseau](https://www.linkedin.com/in/laurebrosseau).