DDD Objetos de valor como atributos de clase.
Tags: ddd, php, entities, development
Published: 2020-09-07 06:48:53

# DDD Objetos de valor como atributos de clase.

En un poco de contexto, Domain Driven Design (`DDD`) es una forma de desarrollar software en capas, dando prioridad a la lo lógica del negocio (o dominio), unificando el lenguaje de expertise de negocio con el lenguaje técnico en algo conocido como `Ubiquitous Language` y utilizando los principios `SOLID` como el medio para lograr el producto final.



Dentro de la metodología de DDD los términos relacionados con los objetos más básicos del sistema son las `entidades` y los `objetos de valor`.  Ambos conceptos hacen referencia a una clase representativa de nuestro proyecto, regularmente un sustantivo en un caso de uso, por ejemplo, un usuario, una orden de compra, un artículo de inventario, etc.



La diferencia entre las `entidades` y los `objetos de valor` es que  estos últimos tienden a ser inmutables y mientras que una `entidad` es un recurso que puede cambiar de estado, ser persistido y/o posteriormente eliminado.



Mientras estudiaba DDD me encontré con una implementación en la que los atributos de las clases pasaban de ser un tipo primitivo (por ejemplo, string o int)  a un objeto de valor. 



Para ejemplificarlo en detalle, supongamos que tenemos una clase `Usuario` que tiene los atributos `nombre` y `edad`:



```php
# User.php

class Usuario 
{
  /** @var string */
  private $nombre;
  
  /** @var int */
  private $edad;
  
 public function __construct(float $nombre, float $edad)
  {
    $this->nombre = $nombre;
	$this->edad = $edad;
  }
}
```



### Clase con objetos de valor como atributos



Primero que nada, se tenía una clase para representar el tipo de dato `string`:



```php
# StringValueObject.php

class StringValueObject 
{
  /** @var string */
  protected $value;
  
  public function __construct(string $value)
  {
    $this->value = $value;
  }
    
  public function getValue(): string
  {
    return $this->value;
  }
    
  public function toString(): string
  {
    return $this->getValue();
  }
}
```



Posteriormente se tenía una clase para representar el atributo `name` del objeto `Usuario`:



```php
# NombreUsuario.php

class NombreUsuario extends StringValueObject 
{
  public function __construct(string $value)
  {
    parent:__construct($value);
  }
}
```



Lo mismo sucedía para la edad, inicialmente una clase para representar el tipo de dato `int`:

```php
# IntValueObject.php

class IntValueObject 
{
  /** @var int */
  protected $value;
  
  public function __construct(int $value)
  {
    $this->value = $value;
  }
    
  public function getValue(): int
  {
    return $this->value;
  }
    
  public function toString(): string
  {
    return strval($this->getValue());
  }
}
```



Después de una representación del tipo `int`, continúa una clase para representar el atributo `edad` del `Usuario`:



```php
# EdadUsuario.php

class EdadUsuario extends IntValueObject 
{
  public function __construct(int $value)
  {
    parent:__construct($value);
  }
}
```



Finalmente se tenía la clase `Usuario` queda de la siguiente manera:



```php
# Usuario.php

class Usuario 
{
  /** @var NombreUsuario */
  private $nombre;
    
  /** @var EdadUsuario */
  private $edad;
    
  public function __construct(NombreUsuario $nombre, EdadUsuario $edad)
  {
      $this->nombre = $nombre;
      $this->edad = $edad;
  }
}
```



Mi primera reacción fue un notable `WFT?` 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/dgw0lis30nb8150yiaev.jpg)

Después de detenerme a analizar el porqué de todo esto, entendí lo siguiente.



### Delegar reglas de dominio a los objetos de valor

Primero que nada, al crear una clase para cada atributo,  podemos delegar la validación a éstas clases, por ejemplo, en el caso del nombre, nunca aceptaríamos un string vacío, por lo que extenderíamos esa funcionalidad de la siguiente manera:



```php
# NombreUsuario.php

class NombreUsuario extends StringValueObject 
{
  public function __construct(string $value)
  {
    $this->asegurarNombreNoVacio(string $value);
    parent:__construct($value);
  }
    
  private function asegurarNombreNoVacio(string $value)
  {
    if ('' === $value) {
      throw new \InvalidArgumentException('El nombre no puede estar vacío.');
    }
  }
}
```



En dónde, si el valor no es vacío en automático arroja una excepción, lo mismo aplica para las validaciones de la clase `EdadUsuario`, en dónde la edad no puede ser menor a 0, quedando:



```php
# EdadUsuario.php

class EdadUsuario extends IntValueObject 
{
  public function __construct(int $value)
  {
    parent:__construct($value);
  }
    
  private function asegurarEdadMinimaDe0($value)
  {
    if ($value < 0) {
      throw new \InvalidArgumentException('La edad no puede ser menor a 0.'); 
    }
  }
}
```



### Integridad en nuevas instancias



Al delegar las validaciones a un `objeto de valor`, cuando nosotros requiramos una instancia de `Usuario`, no deberemos preocuparnos por la integridad, dado que todos los valores ingresados serían válidos o se detendrá la ejecución mostrando un error.



### Código en un solo lugar



A parte de esto, nos brinda la facilidad de crear atributos compartidos entre clases y "módulos" (conocidos como `sudominios` en DDD), por ejemplo, si el `Usuario` tuviera alguna relación con alguna otra `entidad` como lo puede ser `Rol`, los atributos en formato de `objeto de valor` utilizarán la misma cla, y por ende no necesitaremos duplicar código en todos aquellos recursos compartidos.



## Conclusión

DDD tiene bastantes conceptos interesantes, muchos de ellos parecen hacer el código muy complejo, pero a largo plazo, proporciona una manera muy escalable y mantenible de hacer código, ¿qué te parece la implementación de objetos de valor como atributos de clase?