# Dominando la Modularidad

[🇺🇸 Read in English](https://insightsapex.hashnode.dev/mastering-modularity)

## **Introducción: Modularidad, el Secreto del Código Escalable**

En el desarrollo con Oracle APEX, muchos proyectos comienzan rápido… y también se complican rápido.
A medida que las aplicaciones crecen, las páginas se multiplican, los procesos se duplican y los cambios se vuelven riesgosos.

Ya hemos hablado de [Buenas Prácticas](https://insightsapex.hashnode.dev/oracle-apex-mejores-practicas-esenciales), [Seguridad](https://insightsapex.hashnode.dev/seguridad-en-oracle-apex-guia-esencial), [UX](https://insightsapex.hashnode.dev/mejorando-la-experiencia-del-usuario-ux) y [Rendimiento](https://insightsapex.hashnode.dev/oracle-apex-rapido-optimizacion-rendimiento). Ahora toca hablar de **arquitectura**.

Aquí es donde entra en juego la **modularidad**: la capacidad de construir aplicaciones Oracle APEX organizadas en piezas reutilizables, independientes y mantenibles.  
Una aplicación modular **reduce errores, acelera el mantenimiento y facilita el trabajo en equipo.**

Si trabajas en equipos o mantienes varias aplicaciones Oracle APEX, entender y aplicar modularidad puede cambiar por completo tu flujo de desarrollo.

En este *APEX Insights*, construiremos una arquitectura modular desde cero, explorando tres pilares clave:

1. **Paquetes PL/SQL** para encapsular la lógica de negocio.  
2. **REST Data Sources** para compartir datos y servicios entre aplicaciones.  
3. **Componentes compartidos de Oracle APEX** para mantener coherencia visual y funcional.  

Usaremos un ejemplo técnico: un **módulo de autenticación y logs centralizado**, reutilizable por varias aplicaciones Oracle APEX dentro del mismo workspace.

---

## **1. Conceptos Clave: Qué Significa Modularidad en Oracle APEX**

Antes de escribir una sola línea de código, entendamos qué buscamos con un diseño modular:

- **Separación de responsabilidades:** cada módulo tiene una función clara (ej. autenticación, notificaciones, configuración).  
- **Reutilización:** la lógica y los componentes pueden ser usados en más de una aplicación.  
- **Mantenibilidad:** los cambios en un módulo no rompen los demás.  
- **Desacoplamiento:** los módulos interactúan a través de interfaces (como paquetes o REST APIs), no directamente entre sí.  

Estos principios son la base de toda arquitectura sostenible, sin importar el tamaño o complejidad del proyecto.

---

## **2. Estructura Recomendada del Proyecto Modular**

Antes de escribir código, define una estructura clara.  
Esta puede parecer un detalle menor, pero te ahorrará horas de mantenimiento más adelante.

**Estructura inicial sugerida:**
```
/apex-insights/
│
├── db/
│   ├── packages/
│   │   ├── auth_core.pks
│   │   ├── auth_core.pkb
│   │   ├── log_utils.pks
│   │   ├── log_utils.pkb
│   └── install/
│       ├── create_users.sql
│       ├── seed_data.sql
│
├── rest/
│   ├── auth_api/
│   │   ├── get_user_status.sql
│   │   ├── post_login_audit.sql
│   └── system_monitor/
│       ├── get_logs.sql
│
├── apex/
│   ├── shared_components/
│   │   ├── templates/
│   │   ├── lists/
│   │   ├── substitutions/
│   └── apps/
│       ├── core_app/
│       ├── admin_app/
│       └── user_portal/
└── docs/
    └── architecture.md
```

**Consejos clave:**
- Usa un prefijo para tus paquetes (ej. `core_`, `mod_`, `app_`).  
- Mantén separados los scripts de instalación e inicialización.  
- Documenta las dependencias entre módulos (idealmente en `architecture.md`).

---

## **3. Módulo 1: Paquetes PL/SQL — El Corazón del Backend**

Los **paquetes PL/SQL** son la base de toda arquitectura modular en Oracle.  
Permiten centralizar la lógica de negocio y exponer funciones limpias y reutilizables.

Los paquetes no solo agrupan procedimientos: **protegen tu lógica de negocio** y evitan duplicaciones en diferentes aplicaciones.

### **Ejemplo: Paquete de Autenticación**

**auth_core.pks**
```plsql
CREATE OR REPLACE PACKAGE auth_core AS
  FUNCTION validate_user(p_username VARCHAR2, p_password VARCHAR2) RETURN BOOLEAN;
  PROCEDURE register_login(p_username VARCHAR2);
END auth_core;
/
```

**auth_core.pkb**
```plsql
CREATE OR REPLACE PACKAGE BODY auth_core AS

  FUNCTION validate_user(p_username VARCHAR2, p_password VARCHAR2) RETURN BOOLEAN IS
    v_count NUMBER;
  BEGIN
    SELECT COUNT(*) INTO v_count
    FROM users
    WHERE username = p_username
      AND user_password = STANDARD_HASH(p_password, 'SHA256');
    RETURN v_count = 1;
  END validate_user;

  PROCEDURE register_login(p_username VARCHAR2) IS
  BEGIN
    INSERT INTO login_audit (username, login_time)
    VALUES (p_username, SYSDATE);
  END register_login;

END auth_core;
/
```

💡 **Consejo:** coloca los paquetes de negocio en un *schema centralizado* (`CORE_DB` o `APEX_UTILS`) y accede a ellos desde cualquier app Oracle APEX con privilegios limitados (`GRANT EXECUTE ON auth_core TO app_user;`).

---

## **4. Módulo 2: REST Data Sources — Conectando Aplicaciones**

Cuando varias aplicaciones necesitan los mismos datos o servicios, lo peor que puedes hacer es copiar la lógica.  
Con **REST Data Sources**, puedes centralizar esa información sin reinventar la rueda.

### **Ejemplo: Servicio de Logs (RESTful)**
```sql
-- SQL Handler: GET_LOGS
SELECT username, action, log_date
FROM app_logs
WHERE log_date > SYSDATE - NVL(:DAYS, 7)
ORDER BY log_date DESC;
```

**Configuración recomendada:**
- Endpoint: `/ords/core/logs/`
- Métodos: `GET`, `POST`
- Autenticación: *OAuth2 o APEX Session Cookie*
- Caché: habilita `Cache-Control` para consultas estáticas.

💡 **Consejo:** usa `APEX_WEB_SERVICE.MAKE_REST_REQUEST` para consumir servicios entre apps del mismo workspace y mantener un flujo controlado.

---

## **5. Módulo 3: Componentes Compartidos — Reutilización Visual y Lógica**

Así como el backend tiene sus módulos, la interfaz también puede volverse modular.  
Los **componentes compartidos (Shared Components)** son tu mejor aliado para mantener coherencia visual entre aplicaciones.

Ejemplos comunes:
- **Templates personalizados:** botones, regiones, listas y reportes.  
- **Listas de valores (LOVs) y sustituciones:** definidas una vez, usadas en múltiples apps.  
- **Bundles de JavaScript o CSS:** centralizados en una app base y referenciados por las demás.  

### **Ejemplo: Banner de Sesión Unificado**
En tu app base (por ejemplo, “Core App”), crea una región HTML:
```html
<div class="session-banner">
  Logged in as: &APP_USER.
</div>
```

Luego, usa **“Copy Shared Components”** en otras apps para importar el banner y mantener coherencia visual sin reescribir nada.

---

## **6. Ejemplo Integrado: Módulo de Autenticación y Logs**

Supongamos que tienes tres aplicaciones: **Portal de Usuarios**, **Admin Dashboard** y **Core App**.

1. **Core App:** contiene `auth_core` y `log_utils` (backend).  
2. **Admin Dashboard:** consume REST `/ords/core/logs/` para mostrar auditoría.  
3. **Portal de Usuarios:** usa `auth_core.validate_user` para login.  
4. **Ambas apps:** importan el banner compartido de sesión.

El resultado es un entorno **modular, conectado y fácil de mantener**, donde cada pieza cumple un propósito y puede evolucionar sin romper las demás.

---

## **7. Beneficios de una Arquitectura Modular**

- **Escalabilidad:** agrega nuevos módulos sin romper los existentes.  
- **Colaboración:** distintos equipos pueden trabajar en módulos separados.  
- **Seguridad:** permisos más claros y controlados entre esquemas.  
- **Reutilización:** evita duplicar lógica y componentes.  
- **Depuración más sencilla:** si algo falla, sabes exactamente en qué módulo está.  

---

## **Conclusión: Construye Módulos, No Monolitos**

La modularidad no es un lujo, es una estrategia.  
En Oracle APEX, dividir tu aplicación en **paquetes, servicios REST y componentes compartidos** transforma la forma en que construyes y mantienes tus proyectos.

Empieza por un módulo pequeño — como autenticación o logs — y verás cómo tu entorno Oracle APEX evoluciona hacia algo más escalable, limpio y profesional.

---

## **Referencias y Recursos Útiles**

1. [Oracle APEX REST Data Sources Guide](https://docs.oracle.com/en/database/oracle/application-express/latest/htmdb/rest-data-sources.html)  
2. [Oracle Database PL/SQL Packages and Types Reference](https://docs.oracle.com/en/database/oracle/oracle-database/21/lnpls/plsql-packages.html)  
3. [Joel Kallman’s Blog – Reusability in APEX Components](https://blogs.oracle.com/apex/)  

---

# 🚀 ¿Necesitas un Experto en APEX?

Ayudo a empresas a construir arquitecturas escalables y modulares. Si tu aplicación es un monolito difícil de mantener y necesitas una refactorización profesional, **hablemos**.

[☕ Agendar una Llamada](https://calendly.com/vinnyum/intro-call) | [💼 Conectar en LinkedIn](https://www.linkedin.com/in/vinny-jimenez/)

---