Especificaciones

Se diferencia de la Query sólo en la intención del Use case que lo va a gestionar. En este caso, los Commands buscan modificar información del dominio.

Tiene una complejidad tirando a nula, pero le ponemos un 1, ya que es el valor mínimo si tiene código.

Como principal cometido, representa la información que ha solicitado modificar el usuario al dominio.

Si tuviéramos que comentar sus características más concretas, diríamos que es un DTO. Eso implica que carece de lógica, contiene datos primitivos (Integer, Float, String, Boolean, …) y es inmutable.

Se relaciona con el Command controller que es el que lo crea, y el Command use case, que es el que lo recibe.

Como observaciones, siempre necesita tener un Use case que lo pueda gestionar en exclusiva. Si hubiera más de uno, nuestra aplicación debería fallar.

¿Qué valor me aporta implementar un Command?

• Como DTO, establecerá las reglas principales a nivel de valores primitivos y la cantidad de información que necesita el mensaje para ser útil al Domain. Jugará un papel clave a la hora de que el Command use case pueda hacer su trabajo.
• Habilita la posibilidad de usar un Bus para agregarle funcionalidad o liberarle de responsabilidad al Command use case a través de middlewares, como logging o transaccionalidad

¿Cómo se expresa esta carta en el mundo real?

Como indica el icono de arriba a la izquierda, corresponde a una clase.

1
2
3
4
5
6
7

final readonly class AddFlatCommand
{
    public function __construct(
        public string $id,
        public string $description,
    ) {}
}

 ```kotlin
 ```

1

TODO: Referencias a otras cartas