Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DevCarlosRodriguez/Documentacion-Arccnova-2.0/llms.txt

Use this file to discover all available pages before exploring further.

ArccNova v2 se construye como un monolito modular: un único proceso y una única base de datos PostgreSQL, pero con módulos que tienen límites estrictos definidos por Clean Architecture y comunicación exclusiva a través de proyectos .Contracts. Esta página cubre ADR-001 (decisión del monolito modular) y ADR-002 (reconstrucción greenfield sin migración de datos de v1).

​
ADR-001 — Arquitectura Monolito Modular

Fecha: 2026-06-05 | Estado: Aceptado (actualizado 2026-06-10)

​
Contexto

El equipo de Omni Tech tiene capacidad reducida. ArccNova v2 no tiene usuarios reales todavía. La velocidad de iteración y la simplicidad operativa son la prioridad. Se evaluó si convenía arrancar con microservicios dado que el cliente tiene planes de expansión futura (RH, CRM, etc.).

​
Opciones evaluadas

OpciónDescripción
Monolito Modular ✅Un solo proceso, una sola DB, módulos con límites estrictos vía Clean Architecture
Microservicios desde el inicioCada módulo como servicio independiente con su DB y deployment
Monolito tradicionalSin límites de módulo — todo en capas planas

​
Decisión

Monolito Modular. Cada módulo tiene sus propias capas Domain / Application / Infrastructure / Presentation / Contracts, pero se despliegan juntos en un solo proceso (Host.Api) compartiendo una sola base de datos PostgreSQL.
Los módulos solo se comunican entre sí vía sus proyectos .Contracts (tipos POCO sin dependencias). La comunicación directa entre módulos está prohibida. NetArchTest.Rules en los proyectos .Tests verifica estos límites en CI para que no dependan únicamente de la disciplina del equipo.

​
Estructura de capas por módulo

Cada módulo (excepto Hr) sigue el patrón de 6 csproj: 
ArccNova.WebApi/Modules/{NombreModulo}/
├── {NombreModulo}.Domain/           → Entidades, value objects, interfaces de repositorio
├── {NombreModulo}.Application/      → Comandos, queries, handlers, validadores
├── {NombreModulo}.Infrastructure/   → Repositorios EF Core, implementaciones externas
├── {NombreModulo}.Presentation/     → Controllers, endpoints, DTOs de entrada
├── {NombreModulo}.Contracts/        → Tipos POCO compartidos con otros módulos (sin dependencias)
└── {NombreModulo}.Tests/            → Tests unitarios e integración; incluye NetArchTest.Rules
El módulo Hr es la excepción por su tamaño: es un único módulo físico con subcarpetas por contexto delimitado (decisión interna 14), evitando ~48 csproj adicionales.

​
Árbol de módulos del monolito

ArccNova.WebApi/
│
├── Host.Api/                          [hecho] arranque, DI, migraciones con advisory lock
│
├── Shared/
│   ├── Common/                        [hecho] submódulo git; mediator custom
│   ├── Shared.Database/               [hecho] AppDbContext + query filters automáticos
│   ├── Shared.Branch/                 [hecho] contexto Tenant/Branch desde JWT
│   ├── Shared.Web/                    [hecho] BaseApiController, envelope; SSE pendiente
│   ├── Shared.Exceptions/             [hecho]
│   └── Shared.Approvals/              [esqueleto] motor de aprobaciones genérico (ADR-018)
│
└── Modules/
    │
    ├── Foundation
    │   ├── Identity/                  [hecho + extensión RBAC]
    │   ├── Tenants/                   [fase 1]
    │   ├── Branches/                  [fase 1]
    │   ├── Geo/                       [fase 1]
    │   ├── Files/                     [fase 1]
    │   └── BillingSaas/               [fase 1]
    │
    ├── Inmobiliario
    │   ├── Properties/                [fase 2]
    │   ├── Contacts/                  [fase 2]
    │   └── LegalDocs/                 [fase 2]
    │
    ├── Operación Comercial
    │   ├── Sales/                     [fase 3]
    │   ├── Financing/                 [fase 3]
    │   ├── Collections/               [fase 3]
    │   └── Treasury/                  [fase 3]
    │
    ├── Pagos
    │   └── Payments/                  [fase 4] Stripe Connect Express
    │
    ├── Reportes
    │   └── Reports/                   [fase 5]
    │
    ├── Recursos Humanos
    │   └── Hr/                        [nueva fase] módulo físico único con subcarpetas:
    │       ├── Org/
    │       ├── Employees/
    │       ├── Attendance/
    │       ├── Schedules/
    │       ├── Requests/
    │       ├── EmployeeDocs/
    │       ├── Payroll/
    │       └── Vacations/
    │
    └── En duda / Pospuesto
        ├── Rentals/                   [en duda] T04 sin respuesta
        ├── Materials/                 [en duda] T04 sin respuesta
        └── Tax/                       [pospuesto] CFDI y fiscal sin CFDI en esta versión

​
Consecuencias

  • Un solo deployment y una sola base de datos; sin latencia de red entre módulos.
  • Los módulos pueden extraerse como servicios independientes cuando el negocio lo justifique; los límites están diseñados para ello desde el inicio.
  • Los límites de módulo se mantienen con disciplina más NetArchTest.Rules en CI — no hay enforcement técnico automático más allá de eso.
  • Cada sistema futuro independiente (si el CRM no entra al monolito) será su propio monolito hermano con su propia DB — no microservicios compartiendo infraestructura.

​
Actualización 2026-06-10

La premisa original de “cada sistema futuro será su propio monolito hermano” quedó parcialmente superseded: RH/Nómina entra dentro de ArccNova.WebApi como módulo único Hr (ADR-009). El CRM sigue pendiente de su análisis aparte; su inclusión en el monolito se decidirá tras evaluar sus integraciones externas (ver decisiones-internas.md sección 5).

​
ADR-002 — Reset Total: Reconstrucción Greenfield sin Migración de Datos

Fecha: 2026-06-05 | Estado: Aceptado

​
Contexto

El sistema v1 (ArcnovaApp) tiene 107 entidades sin separación de bounded contexts, una capa de servicios plana, mezcla de EF Core y ADO.NET crudo, y cero tests automatizados. El cliente quiere ampliar el alcance funcional (fiscal US, Stripe, CRM) y agregar el mercado de EE.UU. Se evaluó si convenía migrar el v1 incrementalmente o reconstruir desde cero.

​
Opciones evaluadas

OpciónDescripción
Reconstrucción greenfield ✅Nuevo repo, nuevo modelo de datos, v1 sigue vivo en paralelo
Migración incremental del v1Refactorizar el v1 módulo por módulo manteniendo la operación

​
Decisión

Reconstrucción greenfield. El v2 es un nuevo sistema con modelo de datos rediseñado desde cero. No hay ETL ni migración de datos desde el v1. El v1 seguirá operando como sistema legacy hasta que el v2 esté en producción y los clientes hayan migrado manualmente.
El código real del v1 (old/ArcnovaApp/) es la referencia de comportamiento para v2: cuando el cliente no recuerde la regla exacta de un cálculo, el código del v1 es la fuente de verdad sobre cómo funciona hoy. El plan de migración 04-mapeo-modulos.md mapea los 37 controllers y 84 entidades del v1 a módulos v2.

​
Consecuencias

  • Diseño libre sin deuda heredada — el modelo de datos refleja los bounded contexts reales.
  • Sin ETL complejo ni período de coexistencia técnica complicado.
  • El cliente necesita operar con dos sistemas en paralelo durante el desarrollo del v2.
  • La validación con el cliente del scope del v1 es crítica antes de arrancar la Fase 1.

Build docs developers (and LLMs) love

Get started for freeTalk to us