date() en el arquetipo componente de parámetros (PARAM-CTX)ESTADO: Aprobado
FECHA: 2026-07-17
AUTOR: Carlos Alberto Torres Camargo (arquitecto)
RELACIONADOS: ADR-002 (División de Libraries), regla dinámica SAR PARAM-CTX (@SARDynamicRule, SimappeCommons 4.20.0)
El ecosistema Nebula define el arquetipo componente de parámetros con la interface
ContextAdminParam (nebula-commons), marcada con @SARDynamicRule(id = "PARAM-CTX"):
un componente de parámetros no es una entidad de negocio (no tiene ciclo CRUD, se
administra) y por eso SAR le desactiva las aserciones de herencia canónica de entidad
(ASR-PC-LAY-01/02/03) solo a los tipos que la implementan.
El contrato original exigía dos operaciones: get(request) (valor vigente por tenant)
y update(dto, request) (actualización). Faltaba una operación transversal que el
dominio sí necesita: exponer la fecha operativa persistida en base de datos que
administra el componente (p. ej. parametros_facturacion.fecha_sistema, la fecha de
operación del sistema de facturación), sin obligar al consumidor a traerse la
proyección completa de get().
Restricción de estándar Simappe: las respuestas de negocio jamás exponen escalares
crudos; toda proyección viaja encapsulada en un DTO o record.
Se amplía el contrato del arquetipo PARAM-CTX con una tercera operación:
public interface ContextAdminParam<D, R, F> {
R get(HttpServletRequest request);
R update(D valor, HttpServletRequest request);
F date(HttpServletRequest request); // @since 0.2.0
}
date(request) devuelve la fecha operativa persistida del tenant en contexto,LocalDate crudo.F del contrato y cada componente define sunebula-models (mismo criterio de división de libraries del ADR-002:nebula-commons, modelos en nebula-models). Así cada componentefechaSistema, etc.) en el nombre del campo.nebula-invoicing):
FechaSistemaResponse(LocalDate fechaSistema) ennebula-models (billing.record.parametrosfacturacion).ParametrosFacturacionComponent.date() reusa la fila única del tenantget()), audita elEventType.READ) y proyecta fecha_sistema.GET /api/v1/parametros-facturacion/date (fachada@Operation +@ExampleObject.implements del tipo, no por la lista de métodos. El rationale de la anotación| Alternativa | Por qué NO |
|---|---|
Record canónico único en nebula-commons (p. ej. ContextParamDate(LocalDate value)) |
Uniforma la forma pero pierde la semántica por componente (el campo se llamaría value); además mete un modelo de proyección en la library de contratos, contra la división del ADR-002. |
Devolver LocalDate crudo |
Rompe el estándar Simappe (escalares crudos prohibidos en respuestas) y cierra la puerta a enriquecer la proyección sin breaking change. |
Que el consumidor use get() y lea la fecha de la proyección completa |
Acopla al consumidor a toda la respuesta del componente y encarece el uso transversal más frecuente (solo la fecha). |
Método default para no romper implementadores |
Un default que retorna null viola Javadoc/contrato; el arquetipo tiene un único implementador y el breaking change se gobierna con SemVer (0.2.0). |
Positivas
get().Negativas / riesgos
<D, R> → <D, R, F> ynebula-commons 0.1.0 → 0.2.0-SNAPSHOT; tododate().GET /date de facturación queda fuera de 08_Contracts de HT_FAT_001contracts.openapi.yaml de esa HT es stub pendiente); al materializar ese| Repo | Rama | Cambio | Versión |
|---|---|---|---|
nebula-commons |
feature/param-ctx-date |
ContextAdminParam<D,R,F> + date() + test de forma (3 métodos) |
0.2.0-SNAPSHOT |
nebula-models |
feature/param-ctx-date |
FechaSistemaResponse (billing) |
0.6.4-SNAPSHOT |
nebula-invoicing |
feature/param-ctx-date |
date() en Component + Service + GET /date + 4 tests nuevos |
1.3.0-SNAPSHOT |
Builds y suites en verde: nebula-commons 4 tests, nebula-invoicing 76 tests.