Crear una estructura fija de razones

Una familia propia resulta útil cuando varios productores y consumidores necesitan compartir el mismo vocabulario. Por ejemplo, una importación identifica libros, hojas, filas, celdas e infracciones.

1. Diseñar los niveles

Define primero qué identifica cada nodo y qué datos necesita quien consume el diagnóstico:

Libro: nombre del archivo
└── Hoja: nombre
    └── Fila: número
        └── Celda: dirección
            └── Infracción: código y datos de la regla

Estos niveles representan contexto; las hojas del árbol explican el incumplimiento. Agrega los niveles que tu aplicación realmente necesite.

2. Elegir la raíz

Base	Uso
Error<TSelf>	Diagnóstico general
DomainError<TSelf>	Datos o reglas de negocio incumplidas
ProcessError	Fallo al ejecutar una operación

TSelf representa el tipo concreto en las bases genéricas. Los procesos usan Greencore.Platform.Processes: su raíz es ProcessError (no genérica) y sus razones usan ProcessReason<TParent, TSelf>.

3. Declarar el padre de cada razón

En DomainReason<TParent, TSelf> o ProcessReason<TParent, TSelf>, el primer argumento indica el padre permitido y el segundo la razón concreta. En Excel, ExcelCellReason declara ExcelRowReason como padre.

El compilador comprueba esa compatibilidad al componer el árbol. El diseño sigue siendo extensible: otra razón puede declarar el mismo padre. Una estructura tipada tampoco valida automáticamente que una dirección de celda o un número de fila sean correctos; esa comprobación pertenece a tus clases.

4. Separar código, mensaje y datos

Usa códigos estables para clasificar causas, mensajes para comunicarlas y propiedades para datos como Address, Number o ExpectedFormat. Los consumidores deben poder obtener la ubicación sin analizar el mensaje. Las propiedades no se convierten automáticamente en metadatos ni aparecen necesariamente en ToString().

5. Agregar métodos de composición

Un método como AddCell puede crear y devolver la celda agregada. Otro como Required puede añadir la infracción y devolver la celda para continuar agregando causas hermanas.

Mantén una convención clara: AddReason devuelve el hijo y WithReason devuelve el receptor. Conserva nodos intermedios en variables cuando eso facilite agrupar varios fallos; crear dos filas con el mismo número produce dos nodos distintos.

6. Construir y consumir

La aplicación detecta las infracciones y después crea el diagnóstico. Los consumidores recorren las razones por tipo y recuperan sus propiedades y padres. Un nodo recién creado puede no tener padre hasta que se adjunte.

Continúa con los tipos completos de importación de Excel y con una familia distinta para fallos de escritura.