LAS SIETE
SECCIONES
Todos los proyectos POP comparten la misma arquitectura base. Las siete secciones son fijas. Lo que varía es su contenido. No importa si es una app móvil, un videojuego, una herramienta de escritorio o un sitio web estático, la estructura no cambia.
Esto tiene una ventaja concreta: cuando alguien llega a un proyecto POP por primera vez, ya sabe dónde buscar. No hay que aprender la arquitectura de cada proyecto porque la arquitectura es siempre la misma.
estructura/
Qué existe y cómo está organizado visualmente. Pantallas, páginas, ventanas, escenas, componentes de interfaz. Todo lo que el usuario ve directamente.
estetica/
Cómo se ve. Colores, temas, tipografías, animaciones, estilos globales. Todo lo visual que no es estructura pero que define la identidad del producto.
funciones/
Qué hace el proyecto. Acciones organizadas por dominio de negocio. Es la sección más grande y más importante. Aquí vive toda la lógica.
datos/
Qué almacena y cómo está estructurado. Moldes y Registros organizados por dominio. Define la forma de los datos, no dónde se guardan.
conexion/
Con qué se comunica externamente. APIs, bases de datos, sockets, sistemas de archivos, servicios de terceros. Todo lo que cruza los límites del proyecto.
configuracion/
Cómo se comporta el proyecto según el contexto. Variables de entorno, idioma, permisos, feature flags. Todo lo que cambia entre producción, desarrollo y test.
assets/
Recursos estáticos externos que el proyecto usa pero no genera. Imágenes, iconos, audio, video, fuentes, modelos 3D. No se transforman, solo se consumen.
| Sección | Pregunta que responde | Nunca contiene |
|---|---|---|
| estructura/ | ¿Qué ve el usuario? | Lógica de negocio, datos crudos |
| estetica/ | ¿Cómo se ve? | Componentes interactivos, datos |
| funciones/ | ¿Qué hace? | Definición de datos, estilos |
| datos/ | ¿Cómo está estructurada la información? | Lógica de procesamiento, conexiones |
| conexion/ | ¿Con qué habla externamente? | Lógica de negocio, definición de datos |
| configuracion/ | ¿Cómo se comporta según el entorno? | Código de producción, assets |
| assets/ | ¿Qué recursos consume? | Código, configuración, lógica |
ORGANIZACIÓN
POR DOMINIO
Las secciones son el nivel 1. El dominio de negocio es el nivel 2. Un dominio es un contexto de negocio coherente: usuario, producto, pedido, inventario, pago. No es un tipo técnico.
La regla es directa: si la lógica habla de usuarios, va en funciones/usuario/. Si los datos describen productos, van en datos/producto/. La pregunta "¿de qué habla esto?" siempre tiene una respuesta, y esa respuesta es el dominio.
LA MISMA
ESTRUCTURA EN TODAS
La arquitectura de siete secciones no cambia con la plataforma. Cambia el contenido de cada sección, pero las siete secciones siempre están. Eso significa que un desarrollador que conoce POP puede orientarse en cualquier proyecto POP sin importar si es web, móvil, escritorio o videojuego.
Aplicación web
App móvil
Videojuego
App de escritorio
POP A
ESCALA
Un proyecto pequeño tiene dos o tres dominios. Un proyecto mediano tiene ocho o diez. Un proyecto grande puede tener treinta. La estructura no cambia, solo crece dentro de las mismas secciones.
Cuando un dominio crece demasiado, se divide. Si funciones/usuario/ tiene veinte acciones, se separa en funciones/autenticacion/ y funciones/perfil/. Esa división no rompe la arquitectura, la refina.
usuario/ iniciarSesion registrarse nota/ crear eliminar actualizar comun/ validarCorreo
usuario/ Molde.Usuario Molde.Sesion nota/ Molde.Nota
usuario/
iniciarSesion
registrarse
actualizarFoto
cambiarContrasena
verificarEmail
gestionarRoles
cerrarSesion
recuperarAcceso
... 12 acciones más
autenticacion/ iniciarSesion registrarse cerrarSesion recuperarAcceso verificarEmail perfil/ actualizarFoto cambiarContrasena actualizarDatos roles/ asignarRol revocarRol verificarPermiso
En OOP cuando el proyecto crece se agregan capas: más servicios, más repositorios, más interfaces. En POP cuando el proyecto crece se agregan dominios. Eso mantiene cada sección manejable y el árbol de carpetas legible.
PROYECTOS
REALES
Tres proyectos completos con su arquitectura POP. Cada uno muestra cómo las siete secciones se adaptan al dominio sin cambiar la estructura base.
Blog personal con CMS propio
Sitio estático con panel de administración para crear y editar artículos. Un solo usuario. Sin base de datos externa.
Juego de rol por turnos
RPG 2D con combate por turnos, sistema de inventario, mapa del mundo y guardado de partida. Plataforma: web con JavaScript canvas.
Herramienta de diseño colaborativo
App web donde múltiples usuarios editan un tablero en tiempo real. Tiene autenticación, permisos por rol y exportación de archivos.
MIGRAR
A POP
Migrar un proyecto existente a POP no requiere reescribir todo. Se puede hacer de forma incremental, dominio por dominio, sin romper lo que ya funciona.
Crear las siete carpetas en el proyecto sin mover nada. El código existente sigue donde está. Solo se establece el destino.
Listar los contextos de negocio del proyecto. Usuario, producto, pedido, etc. Sin mover código todavía.
Elegir el dominio más pequeño y mover su código a la nueva estructura. Verificar que sigue funcionando antes de continuar con el siguiente.
A medida que se mueve el código, agregar las declaraciones de entrada, resultado y posibles fallas en formato POP, aunque sea como comentarios.
Solo cuando todo está migrado y probado, eliminar la estructura original. No antes.
LIMITACIONES
CONOCIDAS
POP es una propuesta conceptual en desarrollo. Estas son las preguntas que aún no tienen respuesta y los problemas que aún no están resueltos.
No está probado si siete secciones son suficientes para proyectos con más de cien dominios. Puede necesitar un nivel de agrupación adicional como módulos o bounded contexts.
La notación de Molde, Acción, Registro y Solución es descriptiva. No existe una especificación gramatical que permita construir un compilador o parser real.
No hay linter, formateador ni validador. La adherencia a POP depende del criterio del desarrollador. En equipos grandes eso introduce inconsistencias difíciles de detectar.
Las Acciones son stateless por diseño. Los casos donde el estado persiste entre llamadas, como sesiones activas o conexiones persistentes, no tienen una estrategia definida.
Hay lógica que genuinamente pertenece a varios dominios. La regla "un propósito, un lugar" no siempre resuelve esa ambigüedad de forma obvia.
No hay datos sobre cuánto mejora o empeora la productividad de un equipo usando POP. La propuesta se basa en razonamiento, no en mediciones.
HOJA DE
RUTA
Lo que viene, en orden de prioridad.
Definir la gramática completa. Moldes con tipos, Acciones con firmas completas, Soluciones con condiciones. Suficiente para que una herramienta la entienda.
Un prototipo que traduzca POP a JavaScript o Python. El objetivo no es producción, es validar que la especificación funciona en la práctica.
Dos o tres proyectos medianos construidos con POP estrictamente. Medir tiempo de orientación para nuevos integrantes y frecuencia de ubicación errónea de archivos.
Mismo proyecto, dos equipos, dos paradigmas. Medir productividad, errores de organización y tiempo de incorporación de desarrolladores nuevos.
Linter de los siete principios, plantillas de proyecto para web, móvil, escritorio y juegos, y documentación pública con ejemplos reales.