Engineering case study

Cómo construí FieldOps:
del problema a una
plataforma completa.

Un proyecto Full Stack diseñado para demostrar arquitectura, producto, calidad y decisiones técnicas en un sistema de operaciones reales.

Full StackProduct designSystem designSpec-driven development
Arquitectura de FieldOps: aplicaciones Angular (portal del equipo, experiencia del técnico y portal del cliente) conectadas a una API .NET 10 con las capas Application (CQRS), Domain (DDD) e Infrastructure (EF Core), que persiste en PostgreSQL y almacenamiento de archivos. CI/CD con GitHub Actions, Docker, auditoría y permisos por rol.
Angular 22.1
Frontend moderno y reactivo
.NET 10
API robusta y escalable
PostgreSQL
Datos relacionales confiables
50 domain entities
Modelo de dominio completo
3 user experiences
Equipo, técnicos y clientes
El reto

Modelar una operación completa,
no solo una interfaz.

Gestionar solicitudes, cotizaciones, órdenes de trabajo, visitas, técnicos, facturas y pagos en un mismo sistema, manteniendo aislamiento por organización (tenant) y control de permisos por rol.

Producto

Flujos completos de principio a fin.

Arquitectura

Separación clara entre dominio, aplicación e infraestructura.

Experiencia

Portales adaptados al equipo, técnicos y clientes.

Arquitectura

Una base preparada para crecer.

Una arquitectura en capas que separa claramente las responsabilidades, facilita el mantenimiento y permite evolucionar el sistema sin afectar el núcleo del negocio.

  • Clean Architecture
    Capas bien definidas y bajo acoplamiento.
  • Tenant isolation
    Datos aislados por organización.
  • Role-based access
    Control de acceso por rol y sucursal.
  • Auditable actions
    Registro de eventos importantes.
  • Versioned database migrations
    Migraciones versionadas y revisadas.
Tecnologías

Elegidas por su capacidad, no por moda.

Frontend

  • Angular 22.1
  • TypeScript
  • Signals
  • RxJS
  • PrimeNG
  • SCSS

Backend

  • .NET 10
  • C#
  • CQRS
  • DDD
  • EF Core
  • REST APIs

Data & infrastructure

  • PostgreSQL
  • Docker Compose
  • GitHub Actions

Quality

  • ESLint
  • Prettier
  • Tests (unitarios e integración)
  • Code review
  • Audit trail
Spec-driven development

Cada feature comenzó con
decisiones explícitas.

Diseño, reglas de negocio y criterios de aceptación antes de escribir código.

  1. Diseño
    Mockups y estados
  2. SPEC
    Reglas y alcance
  3. Arquitectura
    Contratos y datos
  4. Implementación
    Frontend y backend
  5. Auditoría
    QA, seguridad y accesibilidad
Decisiones técnicas

Los retos que definieron el proyecto.

Multi-tenancy

Evitar cruces de información entre organizaciones.

Problema decisión resultado

Estados y transiciones

Mantener consistencia entre solicitudes, cotizaciones, trabajos y visitas.

Problema decisión resultado

Permisos por rol y sucursal

Autorizar tanto la interfaz como cada operación del servidor.

Problema decisión resultado

Trazabilidad

Registrar cambios importantes sin exponer información sensible.

Problema decisión resultado
Calidad y entrega

Construido como si fuera a producción.

  • CI para frontend y backend
  • Migraciones revisadas y no aplicadas automáticamente
  • Validación de aislamiento por organización
  • Pruebas de permisos y flujos críticos
  • Revisión visual, responsive y accesibilidad
Las decisiones y limitaciones también quedan documentadas.
Mi contribución

Diseñé el producto y también
construí sus cimientos.

Definí los flujos, diseñé la experiencia, modelé el dominio y desarrollé la arquitectura Full Stack apoyándome en un proceso iterativo asistido por IA y validado mediante revisiones técnicas.

¿Quieres ver el resultado funcionando?
Explora FieldOps en acción o revisa el código fuente.
Proyecto demostrativo
con datos ficticios.