Tried to improve "Process" doc.
@@ -450,26 +450,25 @@ cases, without involving any other components.
Commands
--------
-Commands have been discussed so far as methods on aggregate objects. Here, system
-commands are introduced, as event sourced aggregates created within a separate
+Commands have been discussed previously as methods on
+:doc:`aggregate objects </topics/domainmodel>`. Here, system commands
+are introduced, as event sourced aggregates created within a separate
"commands application".
-One advantage of using a separate commands application is that commands can be
-introduced into an event processing system without interrupting the flow
-of event processing by the other process applications (due to potential
-contention writing to the application's notification log). A commands
-application does not need to follow any other applications, in which case
-there is no event processing to interrupt. Hence, normal application command
-methods can be used on a commands application to create commands, and
-another process application can follow it and thereby process the commands,
-without causing anything to need retrying.
-
-Responses can be collected on the command aggregate (see below), in which it will
-need to follow another application. An alternative approach to updating the
-command involves creating separate "command response" aggregates in a "responses"
-application. Another advantage of having distinct commands is that old commands
-can be used to check the same application state is generated by a new version
-of the system.
+One advantage of having distinct command aggregates is that old commands
+can be used to check the same application state is generated by a new
+version of the system.
+
+Another advantage of using a separate commands application is that commands
+can be introduced into an event processing system without interrupting the
+event processing of the core process applications. (Treating a process
+application as a normal application certainly works, but can potentially
+cause contention writing to the notification log.)
+
+Responses can be collected by creating separate "command response" aggregates
+in a separate "responses" process application. An alternative approach involves
+updating the command aggregate, and having the commands application follow a core
+process application.
In the example below, the command class ``CreateOrder`` is defined using the
library's command class, :class:`~eventsourcing.domain.model.command.Command`, which
@@ -478,9 +477,8 @@ class with a method ``done()`` and a property ``is_done``.
The ``CreateOrder`` class extends the library's
:class:`~eventsourcing.domain.model.command.Command`
-class with an event sourced ``order_id`` attribute, which
-will be used to associate the command's objects
-with the orders created by the system in response.
+class with an event sourced ``order_id`` attribute, which will be used to associate
+the command's objects with the orders created by the system in response.
.. code:: python
