Rename Implementations to Infrastructure

Command/Implementations can still be slightly vague. Adjust the title of
 this page to Infrastructure to state this is about the CommandBus you
 would use

Author: smcvb

Diff for: SUMMARY.md

@@ -39,7 +39,7 @@
     * [Conflict Resolution](axon-framework/axon-framework-commands/modeling/conflict-resolution.md)
   * [Command Dispatchers](axon-framework/axon-framework-commands/command-dispatchers.md)
   * [Command Handlers](axon-framework/axon-framework-commands/command-handlers.md)
-  * [Implementations](axon-framework/axon-framework-commands/implementations.md)
+  * [Infrastructure](axon-framework/axon-framework-commands/infrastructure.md)
   * [Configuration](axon-framework/axon-framework-commands/configuration.md)
 * [Events](axon-framework/events/README.md)
   * [Event Dispatchers](axon-framework/events/event-dispatchers.md)

Diff for: axon-framework/axon-framework-commands/README.md

@@ -8,7 +8,7 @@ A summary of the various sub-sections is given below.
 | :--- | :--- |
 | [Modeling](modeling/) | Axon Framework provided components to address Aggregate Modeling concerns |
 | [Command Dispatchers](command-dispatchers.md)/ [Command Handlers](command-handlers.md) | Functional Development concerns for Command Messages using the Axon Framework |
-| [Implementations](implementations.md) | Non-Functional Development concerns for Command Messages using the Axon Framework |
+| [Infrastructure](infrastructure.md) | Non-Functional Development concerns for Command Messages using the Axon Framework |
 | [Configuration](configuration.md) | Configuration concerns for Command Messages using the Axon Framework |
 
 This guide is complemented by a video tutorial which gives a practical demonstration of the concepts explained in this section. The tutorial is available at -> [Axon Coding Tutorial - Command Messages](https://www.youtube.com/watch?v=7oy4w5THFEU&feature=youtu.be)

Diff for: axon-framework/axon-framework-commands/command-dispatchers.md

@@ -5,7 +5,7 @@ The [Command Handlers](command-handlers.md) pages provide the background on how
 1. The Command Bus, and
 2. The Command Gateway
 
-This page will show how and when to use the command gateway and bus. How to configure and specifics on the the command gateway and bus implementations are discussed [here](implementations.md)
+This page will show how and when to use the command gateway and bus. How to configure and specifics on the command gateway and bus implementations are discussed in the [infrastructure](infrastructure.md) section.
 
 ## The Command Bus
 

Diff for: axon-framework/axon-framework-commands/implementations.md renamed to axon-framework/axon-framework-commands/infrastructure.md

@@ -1,4 +1,4 @@
-# Implementations
+# Infrastructure
 
 Command dispatching, as exemplified in the [Dispatching Commands](command-dispatchers.md) page, has a number of advantages. First of all, there is a single object that clearly describes the intent of the client. By logging the command, you store both the intent and related data for future reference. Command handling also makes it easy to expose your command processing components to remote clients, via web services for example. Testing also becomes a lot easier. You could define test scripts by just defining the starting situation \(given\), command to execute \(when\) and expected results \(then\) by listing a number of events and commands \(see [Testing](../testing/) for more on this\). The last major advantage is that it is very easy to switch between synchronous and asynchronous as well as local versus distributed command processing.
 
@@ -142,13 +142,14 @@ MyGateway myGateway = factory.createGateway(MyGateway.class);
 
 ## The Command Bus
 
-The Command Bus is the mechanism that dispatches commands to their respective command handlers within an Axon application. Suggestions on how to use the `CommandBus` can be found [here](command-dispatchers.md#the-command-bus). Several flavors of the command bus, with differing characteristics, exist within the framework:
+The Command Bus is the mechanism that dispatches commands to their respective command handlers within an Axon application. 
+Suggestions on how to use the `CommandBus` can be found [here](command-dispatchers.md#the-command-bus). Several flavors of the command bus, with differing characteristics, exist within the framework:
 
 ### AxonServerCommandBus
 
 Axon provides a command bus out of the box, the `AxonServerCommandBus`. It connects to the [AxonIQ AxonServer Server](../../axon-server-introduction.md) to submit and receive Commands.
 
-`AxonServerCommandBus` is a [distributed command bus](command-dispatchers.md#the-command-bus). It uses a [`SimpleCommandBus`](implementations.md) to handle incoming commands on different JVM's by default.
+`AxonServerCommandBus` is a [distributed command bus](command-dispatchers.md#the-command-bus). It uses a [`SimpleCommandBus`](infrastructure.md) to handle incoming commands on different JVM's by default.
 
 {% tabs %}
 {% tab title="Axon Configuration API" %}
@@ -190,7 +191,7 @@ By simply declaring dependency to `axon-spring-boot-starter`, Axon will automati
 
 > **Excluding the Axon Server Connector**
 >
-> If you exclude `axon-server-connector` dependency you will fallback to 'non-axon-server' command bus options, the `SimpleCommandBus` \(see [below](implementations.md)\).
+> If you exclude `axon-server-connector` dependency you will fallback to 'non-axon-server' command bus options, the `SimpleCommandBus` \(see [below](infrastructure.md)\).
 {% endtab %}
 {% endtabs %}
 
@@ -419,7 +420,7 @@ Sometimes, you want multiple instances of command buses in different JVMs to act
 
 That is where the concept of 'distributing the command bus' comes in. The default implementation of a distributed command bus is the `AxonServerCommandBus`. It connects to the [AxonIQ AxonServer Server ](../../axon-server-introduction.md)to submit and receive Commands. Unlike the other `CommandBus` implementations, the `AxonServerCommandBus` does not invoke any handlers at all. All it does is form a "bridge" between command bus implementations on different JVM's.
 
-By default, [`SimpleCommandBus`](implementations.md) is configured to handle incoming commands on the different JVM's. You can configure `AxonServerCommandBus` to use other command bus implementations for this purposes: [`AsynchronousCommandBus`](implementations.md), [`DisruptorCommandBus`](implementations.md).
+By default, [`SimpleCommandBus`](infrastructure.md) is configured to handle incoming commands on the different JVM's. You can configure `AxonServerCommandBus` to use other command bus implementations for this purposes: [`AsynchronousCommandBus`](infrastructure.md), [`DisruptorCommandBus`](infrastructure.md).
 
 ### DistributedCommandBus
 

Diff for: extensions/kotlin.md

@@ -17,7 +17,7 @@ This section describes the additional functionality attached to Axon's [command
 
 ### CommandGateway
 
-An inlined method has been introduced on the `CommandGateway` which allows the introduction of a dedicated function to be invoked upon success or failure of handling the command. As such it provides a short hand instead of using the [`CommandCallback`](../axon-framework/axon-framework-commands/implementations.md) directly yourself.
+An inlined method has been introduced on the `CommandGateway` which allows the introduction of a dedicated function to be invoked upon success or failure of handling the command. As such it provides a shorthand instead of using the [`CommandCallback`](../axon-framework/axon-framework-commands/infrastructure.md) directly yourself.
 
 Here is a sample of how this can be utilized within your own project:
 

Diff for: extensions/spring-cloud.md

@@ -48,7 +48,7 @@ There are decorators present for the `CapabilityDiscoveryMode`, providing two ad
 The `Registration`, `DiscoveryClient` and `CapabilityDiscoveryMode` are arguably the heart of the `SpringCloudCommandRouter`.
 There are, however, a couple of additional things you can configure for this router, which are the following:
 
-* `RoutingStrategy` - The component in charge of deciding which of the nodes receives the commands consistently. By default a `AnnotationRoutingStrategy` is used (see [Distributing the Command Bus](../axon-framework/axon-framework-commands/implementations.md#distributedcommandbus) for more).
+* `RoutingStrategy` - The component in charge of deciding which of the nodes receives the commands consistently. By default, a `AnnotationRoutingStrategy` is used (see [Distributing the Command Bus](../axon-framework/axon-framework-commands/infrastructure.md#distributedcommandbus) for more).
 * A `ServiceInstance` filter - This `Predicate` is used to filter out `ServiceInstance`s retrieved through the `DiscoveryClient`. For example, it allows the removal of instances which are known to not handle any command messages. This might be useful if you have several services within the Spring Cloud Discovery Service set up, which you do not ever want to take into account for command handling.
 * `ConsistentHashChangeListener` - Adding a consistent hash change listener provides you with the opportunity to perform a specific task if new nodes have been added to the known command handlers set.