Skip to main content

03. Arquitectura del Sistema: MDX-Cloud (Modelo C4 - Nivel 2)

Esta sección detalla la descomposición tecnológica y física de los contenedores que conforman MDX-Cloud. El sistema implementa un modelo completamente desacoplado (Frontend en Cloudflare Pages y Backend en VPS) para garantizar el rendimiento, la seguridad transaccional y la continuidad operativa sin conexión a internet (Offline-First).

03.1 Stack Tecnológico Definitivo​

El ecosistema de producción se estandariza bajo componentes de alta velocidad e independencia de ejecución, sustituyendo la planificación preliminar sincrónica por un entorno asíncrono distribuido:

  • Backend (Servidor de Aplicaciones): ASP.NET Core (.NET 10) estructurado como un Monolito Modular con DDD Ligero (Domain-Driven Design Lite).
  • Frontend (Interfaz de Usuario): Aplicación Single Page Application (SPA) ejecutable en navegador, construida en React + Vite + TypeScript.
  • Persistencia Local (Modo Offline): Base de datos relacional nativa del navegador (IndexedDB) gestionada mediante Dexie.js.
  • Persistencia Central (Base de Datos): PostgreSQL configurado de forma interna en el servidor, con aislamiento lógico absoluto por esquemas (10 Dominios Lógicos).
  • Entorno de Servidor: Servidor Virtual Privado (VPS) ejecutando Linux (Ubuntu Server) detrás de un proxy inverso.

03.2 Diagrama de Contenedores y Correspondencia de Dominios​

El siguiente diagrama describe cómo interactúan físicamente las aplicaciones cliente con el backend unificado y cómo se segmentan los datos en PostgreSQL mediante 10 "Islas de Información" (Bounded Contexts):

03.3 Aislamiento de Persistencia y Especificación de Dominios (DDD)​

Para dar cumplimiento a la integridad de la información, aislar lógicamente las responsabilidades y preparar la arquitectura para la futura expansión del negocio (Módulo B2B, Logística, Nóminas/RRHH), la base de datos de MDX-Cloud segmenta su persistencia en 10 esquemas estrictos.

💡 Nota Arquitectónica: Los dominios representan "Islas de Información" (datos y reglas de negocio cohesivas), no departamentos físicos. Un rol gerencial puede interactuar con los 10 dominios sin necesidad de tener un esquema propio.

A continuación, se detalla qué entidades y procesos operativos pertenecen a cada uno de los 10 dominios:

1. Dominio Catálogos Centrales (catalogos.*)​

  • Propósito: Mantener el núcleo de la información del negocio (Core Data), independiente de si se vende o se almacena.
  • Tablas en Base de Datos: productos, producto_presentaciones, categorias_producto, unidades_medida.

2. Dominio Fiscal y SAT (fiscal.*)​

  • Propósito: Aislar las reglas gubernamentales cambiantes (CFDI 4.0) del resto de la lógica de negocio.
  • Tablas en Base de Datos: sat_unidades, sat_productos_servicios, códigos postales, regímenes fiscales.

3. Dominio Comercial & B2B (ventas.*)​

  • Propósito: Gestionar el frente de batalla hacia el mercado (Front-Office) y el ingreso de dinero.
  • Procesos Operativos: Gestión de clientes, reglas de negocio para precios, y captura de pedidos u órdenes de venta (B2B y Mostrador).
  • Tablas en Base de Datos: clientes, pedidos, pedidos_detalle, matriz_precios, despachos_mostrador.

4. Dominio Compras (compras.*)​

  • Propósito: Gestionar la salida administrativa de dinero (Back-Office) para abastecer a la empresa.
  • Procesos Operativos: Gestión de proveedores y negociación mediante órdenes de compra.
  • Tablas en Base de Datos: proveedores, ordenes_compra, ordenes_compra_detalle.

5. Dominio WMS, Logística y Sanitario (wms.*)​

  • Propósito: Controlar de forma absoluta la existencia física real de cajas (Offline y Online) y asegurar el cumplimiento sanitario (COFEPRIS).
  • Procesos Operativos: Recepción física, acomodo en estantes, algoritmo FEFO, picking/surtido digital y transferencias. Este dominio no procesa valores en moneda de venta, solo de costo de inventario.
  • Tablas en Base de Datos: cedis, inventario, lotes, movimientos_inventario (Kardex inmutable), ajustes_inventario, transferencias, alertas_lotes.

6. Dominio Cuentas por Cobrar (credito_cobranza.*)​

  • Propósito: Supervisar el dinero que los clientes deben a la empresa.
  • Procesos Operativos: Estado de cuenta, aplicación de abonos por algoritmo FIFO y bloqueos por impagos.
  • Tablas en Base de Datos: deudas, pagos, aplicacion_pagos.

7. Dominio Tesorería y Cuentas por Pagar (tesoreria.*)​

  • Propósito: Controlar el flujo de efectivo y el dinero que la empresa le debe a proveedores.
  • Procesos Operativos: Programación de pagos a proveedores y control de viáticos (Preparación Fase 2).
  • Tablas en Base de Datos: cuentas_por_pagar, pagos_emitidos.

8. Dominio Facturación Electrónica (cfdi.*)​

  • Propósito: Encargado exclusivo de la emisión, cancelación y resguardo de comprobantes fiscales (CFDI).
  • Decisión Arquitectónica de Almacenamiento: El sistema guarda permanentemente el XML original en Cloudflare R2 (Bóveda Histórica), y solo la URL en Postgres, garantizando soberanía tecnológica sobre Factura.com.
  • Tablas en Base de Datos: comprobantes.

9. Control de Acceso y Usuarios (usuarios.*)​

  • Propósito: Control de identidad y seguridad del ERP.
  • Procesos Operativos: Autenticación JWT y control de acceso basado en roles (RBAC) para el personal operativo.
  • Tablas en Base de Datos: usuarios (credenciales y roles).

10. Esquema Transversal de Auditoría (auditoria.*)​

  • Propósito: Bitácora forense de seguridad inalterable.
  • Procesos Operativos: Intercepción de Entity Framework Core para capturar estados previos y nuevos (Data Tracking).
  • Tablas en Base de Datos: logs (formato JSONB polimórfico).

11. Dominio de Configuración del Sistema (configuracion.*)​

  • Propósito: Aislar las variables de infraestructura y secretos técnicos del resto de la lógica de negocio.
  • Procesos Operativos: Gestión de credenciales SMTP, llaves del PAC (Factura.com), variables de entorno y toggles (Sandbox/Producción).
  • Tablas en Base de Datos: parametros_globales, credenciales_api.

⚠️ Regla de Desarrollo (Aislamiento Parcial): Se permite el uso de Llaves Foráneas (FKs) físicas cruzando distintos esquemas en la base de datos única y exclusivamente como Red de Seguridad (Fallback). Sin embargo, el código C# no debe utilizar las excepciones de base de datos para manejar su lógica; la comunicación y validación entre dominios se seguirá resolviendo en la capa de aplicación exponiendo contratos limpios en memoria (.Contracts) y ejecutando Transacciones Síncronas unificadas.

03.4 Expansión del Sistema (Módulos vs Dominios)​

(Última modificación: 2 de Junio de 2026)

Es fundamental entender la diferencia arquitectónica entre un Módulo (lo que ve y usa el usuario final, como una pantalla o una App) y un Dominio (cómo se guardan y aíslan los datos en la base de datos).

Los 10 dominios establecidos son definitivos y estructurales. No se debe crear una nueva base de datos o esquema por cada pantalla nueva. Los futuros módulos visuales del sistema (por más complejos que sean) se construirán orquestando la información de estos 10 pilares, simplemente añadiendo nuevas tablas dentro de los esquemas existentes.

A continuación, se presentan dos ejemplos de cómo sistemas complejos se integrarían utilizando puramente los dominios existentes:

Ejemplo 1: Sistema de Logística de Entrega (Última Milla)​

Si se desea construir una aplicación para los choferes repartidores, su núcleo de datos residiría en el dominio de Logística (wms.*).

  • Expansión de Tablas: Dentro del esquema wms.* se agregarían tablas como wms.vehiculos, wms.rutas_entrega y wms.evidencias_entrega.
  • Orquestación del Módulo:
    1. Armado: Los almacenistas preparan los paquetes (wms.movimientos_inventario).
    2. Asignación: Se asigna la ruta al chofer leyendo su perfil del dominio de RRHH (personal.empleados).
    3. En Camino: La App móvil del chofer consulta el dominio Comercial (ventas.pedidos) para saber la dirección del cliente en el mapa.
    4. Entrega Final: El chofer toma la firma. El sistema guarda la evidencia en wms.* y envía un mensaje interno (Evento) a ventas.* para marcar el pedido como "Entregado".

Como se observa, el sistema crece orgánicamente sin fragmentar la base de datos más allá de los 10 dominios estructurales, garantizando que el Modular Monolith siga siendo ágil y mantenible a largo plazo.