Desarrollo CORE

1. 1. Filosofía de Diseño

• De "Pantalla" a "Dominio": Abandonamos la idea de diseñar tablas mirando el formulario (Figma) y adoptamos Domain-Driven Design (DDD).
• Separación de Esquemas: Organizamos la base de datos en módulos lógicos para seguridad y orden:
• `global`: Catálogos estáticos (Países, Monedas, Estados).
• `core`: La bóveda de identidad (Personas).
• `riesgo`, `socioeconomico`, `relaciones`: Satélites contextuales.
• `auditoria`: Log histórico.
• `seguridad`: Usuarios y roles.

1. 2. Estándares Técnicos (PostgreSQL & Spring Boot)

• Claves Primarias (PK):
• Usaremos `BIGINT` para tablas transaccionales (Personas, Movimientos) y `INT` para catálogos.
• Estrategia: `GENERATED BY DEFAULT AS IDENTITY`. Esto nos permite insertar los IDs del sistema viejo manualmente durante la migración, y luego dejar que Postgres siga la secuencia automáticamente.

• Tipos de Datos Críticos:
• Moneda: `NUMERIC` (Cero errores de redondeo).
• Fechas: `TIMESTAMPTZ` (Con zona horaria) para auditoría y `DATE` para hitos (nacimiento).
• Flexibilidad: `JSONB` para guardar respuestas crudas de APIs (Informconf) o logs.

• Nomenclatura: `snake_case` estricto, nombres de constraints explícitos (`pk_`, `fk_`, `uq_`).

1. 3. Modelo de Personas (Gen/Spec)

• Herencia de Datos: Elevamos (promovimos) campos comunes a la tabla padre `core.personas` para facilitar búsquedas polimórficas:
• `fecha_nacimiento_constitucion` (Edad/Antigüedad).
• `actividad_economica` y `regimen_tributario`.
• Datos de contacto base (`email`, `telefono`, `web`).

• Tablas Hijas: `personas_fisicas` y `personas_juridicas` solo contienen lo que es biológica o legalmente exclusivo de ellas.

1. 4. Estrategia de Auditoría (Modelo Híbrido)

• Operativa (Rápida): Todas las tablas tienen columnas `creado_por`, `creado_en`, `actualizado_por`, etc. para mostrar info en pantalla sin JOINs pesados.
• Forense (Profunda): Una tabla centralizada `auditoria.logs_eventos` que guarda el JSON del cambio (`before` / `after`).
• Particionamiento: Esta tabla se divide físicamente por años (`_y2025`, `_y2026`) para rendimiento y mantenimiento.

• Desacoplamiento: Las columnas de auditoría (`creado_por`) son `BIGINT` pero NO tienen Foreign Key física contra la tabla de `usuarios`. Esto evita el antipatrón de la "Tabla Dios" y bloqueos de rendimiento.

1. 5. Borrado Lógico y Unicidad

• Soft Delete: Usamos `eliminado_en` (timestamp) en lugar de un flag booleano.
• Identidad Estricta: Decidimos aplicar un Constraint Único Duro sobre el Documento de Identidad (País + Tipo + Número).
• Regla: No puede existir el mismo documento duplicado, ni siquiera si uno está borrado.
• Lógica: Si un ex-socio regresa, el sistema (Java) debe detectar que está borrado lógico y "reactivarlo" (UPDATE) en lugar de crear uno nuevo. Esto preserva el historial.

1. 6. Estrategia de Migración (Legacy)

• Columna `id_legado`: Agregamos este campo (con índice único) en las tablas maestras.
• Permite rastrear el ID original (`CLI-001`) del sistema viejo.
• Facilita los scripts de migración ETL para relacionar tablas (Préstamos viejos -> Personas nuevas).

1. 7. Satélites Polimórficos

• Vínculos: La tabla `relaciones.vinculos_personas` es genérica. Sirve para Padre-Hijo, Empresa-Representante y Empresa-Accionista (con % de participación).
• Riesgo: Las calificaciones y listas negras (PEP/OFAC) apuntan a la tabla padre `personas`, unificando el motor de riesgo.

1. Asunto: Definición de Arquitectura de Base de Datos - Módulo Core Personas

Resumen Ejecutivo:
El módulo implementa un patrón de herencia (Gen/Spec) para centralizar la identidad en una tabla única y especializar los atributos según la naturaleza (Física o Jurídica). Se utiliza el esquema `core` para identidad y `global` para catálogos.

Estructura de Tablas Principales (`schema: core`):

• `core.personas` (Tabla Padre / Identidad):
• Contiene los datos comunes: Identificadores (RUC/CI), País, Datos de Contacto (Email/Tel), Estado del Sistema y Auditoría.
• Regla: Constraint de unicidad sobre `(pais, tipo_doc, numero_doc)`.
• Control: Maneja el borrado lógico (`eliminado_en`) que impacta a las tablas hijas.

• `core.personas_fisicas` (Tabla Hija - Extensión):
• Relación 1:1 con Padre.
• Datos: Nombres, Apellidos, Sexo, Estado Civil, Profesión Base (`ocupacion_id`) y Datos de Vivienda.

• `core.personas_juridicas` (Tabla Hija - Extensión):
• Relación 1:1 con Padre.
• Datos: Razón Social, Nombre Fantasía, Tipo Societario, Segmentación por Ingresos y Cantidad de Empleados.

• `core.direcciones`:
• Tabla satélite para múltiples direcciones por persona.
• Soporta Geolocalización (`latitud`, `longitud`) para Google Maps.

• `core.perfiles_laborales`:
• Registro transaccional de ingresos.
• Diferencia conceptualmente la Profesión (Identidad) del Cargo/Rubro (Circunstancial).
• Vincula con `global.actividades_economicas` tanto para el socio como para el empleador.

• `core.vinculos_personas` (Relacionamiento):
• Tabla recursiva (Persona <-> Persona) para modelar todas las relaciones.
• Usos: Representantes Legales, Accionistas (con %), Grupo Familiar y Garantes.
• Incluye vigencia de mandato (`fecha_vencimiento`) y poderes de firma.

Catálogos Globales Críticos (`schema: global`):

• `actividades_economicas`: Tabla unificada con flags (`aplica_persona`, `aplica_empleador`) para estandarizar rubros.
• `cargos_autoridades`: Roles corporativos (Presidente, Gerente) con flag de `es_alta_gerencia`.
• `ocupaciones`: Profesiones con flag `requiere_datos_laborales` para comportamiento de UI.

Consideraciones Técnicas:

• Auditoría: Todas las tablas transaccionales (no catálogos) incluyen bloque de auditoría completo (`creado_en/por`, `actualizado_en/por`, `eliminado_en/por`).
• Integridad: Se utiliza `ON DELETE CASCADE` en las tablas hijas para mantener consistencia con la tabla padre.

NOTA IMPORTANTE: aquí todavía no están las tablas del módulo de manifestación de bienes y pep.

Versión final de módulo de personas físicas y jurídicas lista para desarollo

EVIDENCIA:
Se adjunta archivo ejecutado en base de datos.