Las Assertions no son exclusivas de DDD. Una aserción es una afirmación contenida en un método que se da con determinados argumentos, este número es mayor que cero, este objeto es el mismo que aquel, estos dos valores son iguales, este objeto es nulo, etc. Si has escrito pruebas unitarias seguramente ya conoces el tipo de método al que me refiero. En su mayoría estos métodos te sirven para verificar estados de objetos primitivos o de muy bajo nivel, por sí mismos no aportan un valor conceptual a tu dominio del problema. Lo único que tienen en común las assertions de tu framework de pruebas unitarias y las aserciones DDD es que sirven para comprobar estados.
Aserciones de alto nivel.
El diseño y construcción de las precondiciones de tus objetos son parte esencial de un lenguaje de dominio robusto, si dejas al azar las pre validaciones vas a ocasionar que existan varias definiciones distribuidas en todos los módulos del sistema sobre que debería de considerarse correcto y que no. Voy a tomar de ejemplo un concepto del dominio de mis sistemas, el RFC. Un RFC Mexicano es un valor alfanumérico que representa a un contribuyente, es el equivalente al TaxID estadounidense. Este objeto de valor puede contener números, letras, el carácter & y puede medir de 10 a 14 caracteres. De acuerdo a la siguiente descripción, ¿cómo puedo definir un valor válido y uno inválido?. A continuación te muestro diferentes implementaciones que he visto con el paso del tiempo que realizan la verificación del estado de un RFC válido:
Como notaste, todas las assertions que fueron escritas son parcialmente válidas. En algunos casos vas a tener falsos positivos y falsos negativos dependiendo de las entradas que reciba el sistema. Esto puede representar un dolor de cabeza para las personas que mantienen y extienden las aplicaciones. El string es incapaz de ofrecer un valor conceptual al programa.
Evita expresar conceptos con datos primitivos.
Los conceptos contenidos en tipos de datos primitivos son una trampa, son fáciles de construir, pero pierden su valor y su razón de ser fácilmente, no aportan significado ni mejoran la legibilidad. Aunque solo trabajes con un valor, trata de darle el mayor significado posible a través de la encapsulación. Si tú defines límites claros del problema, entonces otros programadores no tendrán que suponer, solamente implementar, esta claridad de ideas acelera el desarrollo, reduce el desperdicio y la curva de aprendizaje de los módulos. A continuación te muestro como puedes promover un objeto simple a un objeto de valor con alto significado, en este caso, te muestro la implementación de la estructura RFC a partir de un simple string.
Hay muchas propiedades y estados que no debes conocer, está bien. El propósito de diseñar objetos con alto valor conceptual es que el dominio del problema sea capaz de explicarse a sí mismo :). No hay que leer documentación ni aprender un montón de jerga para poder interpretar un requerimiento.
Construye aserciones con objetos de alto nivel siempre que sea posible.
Así como construyes objetos de alto nivel conceptual con clases y estructuras para mejorar el entendimiento del sistema, debes construir aserciones que sirvan como pre validadores o post-validadores. Obvio, las aserciones pueden usar assertions de tipos primitivos. Lo importante es que tú, como diseñador, definas los límites y restricciones claros que marcan la validez o no validez del estado de un objeto en tu dominio del problema. A continuación te muestro como construí mis Asserts de alto nivel.
Autor imagen: Jen Theodore
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
