Una arquitectura que conserva el orden

Greencore nace para apoyar el desarrollo ordenado con Domain-Driven Design (DDD) y ofrecer una base clara para CQRS. No pretende imponer un framework de aplicación completo: aporta contratos, tipos y primitivas que ayudan a que cada decisión tenga un lugar explícito.

La idea central es sencilla: el dominio expresa las reglas del negocio; la aplicación coordina casos de uso; la infraestructura conecta recursos externos; y la plataforma ofrece capacidades transversales reutilizables.

Los cuatro grupos de módulos

                         ┌─────────────────────────┐
                         │       PLATFORM          │
                         │ capacidades transversales│
                         └───────────┬─────────────┘
                                     │
       ┌─────────────────────────────┼─────────────────────────────┐
       │                             │                             │
┌──────▼──────┐               ┌──────▼──────┐               ┌──────▼──────┐
│   DOMAIN    │               │ APPLICATION │               │INFRASTRUCTURE│
│ reglas      │               │ casos de uso│               │ adaptadores  │
│ del negocio │               │ y CQRS       │               │ externos     │
└─────────────┘               └─────────────┘               └──────────────┘

platform: capacidades transversales

Contiene piezas que pueden ser compartidas por los demás grupos sin representar un negocio concreto: Result, errores estructurados, diagnósticos, validación técnica y coordinación de concurrencia. Estas capacidades hacen visibles los estados esperados y reducen la duplicación entre soluciones.

domain: lenguaje y reglas del negocio

Modela entidades, objetos de valor, especificaciones, invariantes y razones de dominio. El dominio debe poder probarse sin una base de datos, un bus de mensajes o un framework web. Sus tipos describen qué significa que una operación sea válida.

application: coordinación de casos de uso

Orquesta las acciones que el sistema ofrece: recibe una intención, carga o construye el modelo de dominio, invoca sus reglas y devuelve un resultado. Aquí encajan los contratos de comandos, consultas, handlers y puertos que necesita cada caso de uso.

infrastructure: detalles sustituibles

Implementa las conexiones con el mundo exterior: persistencia, mensajería, proveedores, reloj, archivos y otros adaptadores. Depende de contratos definidos más adentro, nunca obliga al dominio a conocer sus detalles.

CQRS como una separación de intenciones

CQRS permite distinguir dos intenciones distintas:

• Un comando solicita un cambio y atraviesa las reglas del dominio.
• Una consulta solicita información y puede optimizar su lectura sin cargar el modelo de escritura.

Greencore busca que esa separación sea explícita y composable. Result permite devolver éxito o fallo esperado sin convertir el flujo normal en excepciones, mientras que los errores tipados conservan el contexto necesario para traducir el resultado en la capa de entrega.

public interface ICommandHandler<TCommand, TResult>
{
    Task<Result<TResult>> Handle(TCommand command, CancellationToken cancellationToken);
}

public interface IQueryHandler<TQuery, TResult>
{
    Task<Result<TResult>> Handle(TQuery query, CancellationToken cancellationToken);
}

Estos contratos ilustran la dirección arquitectónica; una aplicación concreta puede definir sus propios nombres, políticas y composición según sus necesidades.

Dirección de dependencias

Las dependencias deben apuntar hacia conceptos más estables:

1. domain no depende de infrastructure.
2. application depende de domain y de contratos, no de implementaciones concretas.
3. infrastructure implementa los puertos que necesita application.
4. platform se consume de forma selectiva; no debe convertirse en un cajón de utilidades sin límites.

El resultado es una solución donde cambiar el almacenamiento o el transporte no obliga a reescribir las reglas del negocio, y donde un caso de uso puede probarse con dobles sencillos.

Qué aporta Greencore y qué queda fuera

Greencore aporta una base común para expresar resultados, errores, diagnósticos, validación, concurrencia y composición. La organización de proyectos, los límites de cada bounded context, la estrategia de persistencia y la elección del bus de mensajes siguen siendo decisiones de la aplicación.

La visión es avanzar por módulos pequeños y verificables: cada nueva capacidad debe reforzar la claridad del modelo y mantener las dependencias bajo control.

Consulta la referencia de módulos para conocer el estado actual de los paquetes y continúa con la guía de primeros pasos para probar la biblioteca.