4. Organización del Proyecto

La organización del proyecto en la arquitectura CMI sigue una estructura jerárquica estricta, basada en Capas, Módulos y Contenedores.
Esta organización se aplica tanto para proyectos frontend como backend, siguiendo los mismos principios fundamentales de separación, escalabilidad y control estructural.

4.1 Capa configs/ — Configuración Técnica Global

La capa configs/ centraliza todos los elementos de configuración técnica global del proyecto.

• No contiene lógica de negocio.
• No importa estructuras de core/, interface/.
• Toda configuración es accedida a través de su enrutador.

Estructura típica:

configs/
├── env/
├── constants/
├── logger/
└── configs.dart

• env/: Manejo de variables de entorno (.env.defaults, carga de configuración).
• constants/: Constantes globales: códigos de error, mensajes, claves simbólicas.
• logger/: Configuración de logs, auditorías, integración de monitoreo.
• configs.dart: Enrutador de la capa configs.

Reglas de la capa configs/:

• No contiene lógica activa del dominio.
• No importa ni depende de core/, interface/.
• Todo acceso externo debe realizarse a través de configs.dart.

---

4.2 Capa core/ — Núcleo Lógico

La capa core/ contiene toda la lógica de negocio y reglas del dominio.
Es independiente de mecanismos de entrada o de cualquier tecnología particular.

Se divide en dos módulos obligatorios:

• rules/: Definiciones abstractas, contratos y estructuras del dominio.
• use/: Implementaciones concretas de las operaciones definidas en rules/.

4.2.1 Módulo rules/ — Definiciones del Dominio

rules/
├── data/
├── services/
├── consumers/
└── rules.dart

• data/: Entidades, objetos de valor y estructuras base del dominio.
• services/: Contratos de servicios técnicos.
• consumers/: Operaciones públicas declarativas.
• rules.dart: Enrutador de exposición de contratos.

Reglas:

• No contiene lógica operativa.
• No importa desde use/, configs/, interface/.
• Solo expone contratos a través de su enrutador.

4.2.2 Módulo use/ — Implementación de Operaciones

use/
├── consumers/
├── services/
├── adapters/
├── origins/
└── uses.dart

• consumers/: Implementaciones de operaciones públicas de los contratos definidos en rules/consumers/.
• services/: Implementaciones de los contratos definidos en rules/services/.
• adapters/: Transformadores entre estructuras internas y externas.
• origins/: Resultado original de las bases de datos, APIs, etc.
• uses.dart: Enrutador de exposición de uses/ que expone consumers/ y services/.

Reglas:

• Puede importar desde rules/ y configs/, pero no desde interface/.
• Toda lógica de transformación pasa por adapters/.
• Todo acceso externo pasa por services/.
• Todo es accedido externamente y solo mediante consumers/.

---

4.3 Capa interface/ — Entrada de Backend

La capa interface/ es el único punto de entrada autorizado al proyecto backend.
No contiene lógica de negocio, solo expone, transforma y redirige solicitudes externas hacia el core/.

Se organiza en módulos independientes por tipo de canal de entrada.

4.3.1 Módulo HTTP (http/)

interface/
└── http/
    ├── authentication/
    │   ├── handlers/
    │   ├── middlewares/
    │   └── authentication_http.dart
    ├── mail/
    │   ├── handlers/
    │   └── mail_http.dart
    ├── recovery/
    ├── status/
    ├── users/
    ├── verification/
    └── http.dart

• Cada subestructura organiza un dominio funcional dentro del módulo HTTP.
• Los handlers gestionan las llamadas públicas.
• Los middlewares aplican reglas de acceso o validación.
• Los enrutadores internos exponen los puntos de acceso de cada subdominio.

4.3.2 Módulo CLI (cli/)

cli/
├── commands/
├── options/
└── cli.dart

• commands/: Comandos disponibles.
• options/: Argumentos y configuraciones.
• cli.dart: Enrutador del módulo CLI.

4.3.3 Módulo de Eventos (events/)

events/
├── listeners/
└── events.dart

• listeners/: Reaccionan a eventos.
• events.dart: Enrutador del módulo Events.

4.3.4 Shared Interface (shared/)

shared/
├── middlewares/
└── shared.dart

• middlewares/: Middlewares reutilizables entre canales de entrada.
• shared.dart: Enrutador de exposición compartida.

---

4.4 Capa interface/ — Presentación de Frontend

La capa interface/ organiza la presentación visual de la aplicación.

4.4.1 Layouts (layouts/)

layouts/
└── [layout_name]/
    ├── components/
    ├── pages/
    │   └── [page_internal]/
    │       ├── views/
    │       └── page.dart
    └── [layout_name].dart

• Estructuras globales con navegación interna.
• Gestionan sus propias páginas internas dinámicas dentro de pages/.
• Cada layout posee un enrutador compuesto que inicializa su navegación y controla su contexto visual.

4.4.2 Pages Independientes (pages/)

pages/
└── [page_name]/
    ├── views/
    └── page.dart

• Pantallas completas autónomas, no asociadas a ningún layout global.
• Gestionan su propia composición visual de forma aislada.
• Usadas para: login, registro, error404, etc.

4.4.3 Shared Interface (shared/)

shared/
├── components/
├── dialogs/
├── logic/
├── overlays/
└── shared.dart

• Componentes reutilizables transversales de Interface.
• No contienen navegación ni inicialización.

---

4.5 Reglas Generales de Organización

• Toda estructura tiene su propio enrutador a excepción de los contenedores genericos.
• Los enrutadores definen los puntos de exposición controlada.
• Los enrutadores compuestos asumen inicialización funcional cuando corresponde.
• Ningún archivo interno debe ser accedido sin pasar por su enrutador correspondiente.
• La navegación y composición visual son controladas a nivel de layouts y pages independientes.
• Los entrypoints backend (HTTP, CLI, Events) son canales de entrada desacoplados de la lógica de negocio.

---

Esta organización garantiza que cualquier proyecto bajo CMI mantenga la claridad, escalabilidad y orden, independientemente de su tamaño o evolución.