Comprender el patrón de comando en un contexto DDD

Hace poco estuve leyendo este artículo aquí:https://cuttingedge.it/blogs/steven/pivot/entry.php?id=100. Parece hablar sobre el uso de comandos (http://www.dofactory.com/net/command-design-pattern) en lugar de los servicios de aplicaciones.

Por favor vea el código a continuación:

public sealed class ShipmentController
{
    private readonly ICommandDispatcher dispatcher;

    public void ShipOrder(ShipOrder cmd) => dispatcher.Dispatch(cmd);
}

sealed class CommandDispatcher : ICommandDispatcher
{
    private readonly Container container;

    public void Dispatch(dynamic cmd) => GetHandler(cmd.GetType()).Handle(cmd);

    private dynamic GetHandler(Type type) =>
        container.GetInstance(typeof(ICommandHandler<>).MakeGenericType(type));
}

que reemplaza código como este:http://www.zankavtaskin.com/2013/11/applied-domain-driven-design-ddd-part-6.html

Tengo tres preguntas:

1) ¿Esto dice que debe tener un comando por solicitud de comando en la capa de servicio de la aplicación? ¿No resultaría esto en una explosión de clase, p. si tienes 100 comandos?

2) ¿Qué haces con las consultas CQRS? ¿Creen servicios de aplicación regulares para estos?

3) ¿Qué haces con los escenarios donde extraes de la base de datos (por ejemplo, un pedido); ejecutar un comando en la Orden, p. CalculateTax y luego persistir en la base de datos? Supongo que el flujo sería (¿es así?):

MVC 
Application Service (to extract order from database)
Command (Application Service calls CalculateTaxCommand)

Respuestas a la pregunta(1)

Su respuesta a la pregunta