66161b1566
Sistema NEXUS v3.4 migrado con: Estructura principal: - core/orchestration: Sistema SIMCO + CAPVED (27 directivas, 28 perfiles) - core/catalog: Catalogo de funcionalidades reutilizables - shared/knowledge-base: Base de conocimiento compartida - devtools/scripts: Herramientas de desarrollo - control-plane/registries: Control de servicios y CI/CD - orchestration/: Configuracion de orquestacion de agentes Proyectos incluidos (11): - gamilit (submodule -> GitHub) - trading-platform (OrbiquanTIA) - erp-suite con 5 verticales: - erp-core, construccion, vidrio-templado - mecanicas-diesel, retail, clinicas - betting-analytics - inmobiliaria-analytics - platform_marketing_content - pos-micro, erp-basico Configuracion: - .gitignore completo para Node.js/Python/Docker - gamilit como submodule (git@github.com:rckrdmrd/gamilit-workspace.git) - Sistema de puertos estandarizado (3005-3199) Generated with NEXUS v3.4 Migration System EPIC-010: Configuracion Git y Repositorios
84 lines
2.3 KiB
Markdown
84 lines
2.3 KiB
Markdown
# ADR-003: Multi-Tenancy Schema-Level
|
|
|
|
**Estado:** Aceptada
|
|
**Fecha:** 2025-11-24
|
|
**Responsable:** Architecture-Analyst
|
|
**Proyecto:** ERP Construccion
|
|
|
|
## Contexto
|
|
|
|
El ERP de Construccion debe soportar multiples empresas constructoras/tenants con:
|
|
- Aislamiento de datos seguro (proyectos, presupuestos, INFONAVIT)
|
|
- Performance optimo para grandes volumenes de datos
|
|
- Escalabilidad para multiples desarrollos inmobiliarios
|
|
- Cumplimiento regulatorio (INFONAVIT requiere aislamiento)
|
|
|
|
## Decision
|
|
|
|
**Schema-Level Isolation:** Cada tenant (empresa constructora) tiene su propio schema PostgreSQL.
|
|
|
|
```sql
|
|
-- Constructora ABC
|
|
CREATE SCHEMA tenant_constructora_abc;
|
|
-- Desarrolladora XYZ
|
|
CREATE SCHEMA tenant_desarrolladora_xyz;
|
|
```
|
|
|
|
## Justificacion
|
|
|
|
### Referencia a Gamilit
|
|
- Gamilit usa multi-schema para separar dominios
|
|
- Permisos granulares por schema
|
|
- Backups selectivos por tenant
|
|
|
|
### Referencia a Odoo
|
|
- Odoo usa `company_id` en todas las tablas (row-level)
|
|
- Schema-level es mas seguro y performante para construccion
|
|
|
|
### Alineacion con ERP Generico
|
|
- Misma estrategia de multi-tenancy
|
|
- Migracion de datos sencilla
|
|
|
|
### Especifico para Construccion
|
|
- Proyectos INFONAVIT requieren aislamiento total
|
|
- Cada fraccionamiento puede ser un tenant diferente
|
|
- Auditorias de INFONAVIT facilitan con backups por tenant
|
|
|
|
## Consecuencias
|
|
|
|
### Positivas
|
|
- Aislamiento completo (seguridad maxima)
|
|
- Backups/restore por constructora
|
|
- Migrations por tenant
|
|
- Performance (no filtros WHERE company_id)
|
|
- Cumplimiento INFONAVIT
|
|
|
|
### Negativas
|
|
- Complejidad en gestion de schemas
|
|
- Requiere logica de routing por tenant
|
|
|
|
## Alternativas Consideradas
|
|
|
|
**1. Row-Level (column tenant_id)**
|
|
- Rechazada: Menor seguridad, no cumple INFONAVIT
|
|
|
|
**2. Database por tenant**
|
|
- Rechazada: Overhead de conexiones, dificil mantenimiento
|
|
|
|
## Implementacion
|
|
|
|
### Acciones Requeridas
|
|
- [x] Funcion get_tenant_schema()
|
|
- [x] Middleware de routing por tenant
|
|
- [x] RLS policies por tenant
|
|
- [ ] Scripts de creacion de tenant para INFONAVIT
|
|
|
|
### Criterios de Aceptacion
|
|
- Usuario de Constructora A no puede ver datos de Constructora B
|
|
- Performance igual que single-tenant
|
|
- Auditorias INFONAVIT por tenant funcionales
|
|
|
|
## Referencias
|
|
- [ERP Generico ADR-003](../../erp-generic/docs/adr/ADR-003-multi-tenancy.md)
|
|
- [Gamilit Database Architecture](../../shared/reference/gamilit/database-architecture.md)
|