¿Por qué un Modelo de Dominio Puro debe permanecer desprovisto de dependencias con ORMs o frameworks de UI?

Para dar cabida estricta al Principio de Inversión de Dependencias (DIP). El modelo de dominio resguarda las reglas de negocio y el valor comercial neurálgico de la empresa. Su aislamiento de la infraestructura hace posible ejecutar baterías TDD a velocidades ultrarrápidas en memoria, además de permitir la sustitución del motor de base de datos o de la biblioteca de UI sin riesgo de desestabilizar los invariantes contables.

¿Cómo se pueden validar reglas supeditadas al tiempo sin recurrir al falseamiento global del objeto Date?

Mediante la inyección de una abstracción de reloj: suministrando una dependencia de tipo Clock: () => Date (o una interfaz con un método now(): Date) al constructor del servicio o método de cálculo. En los tests se proporciona una función determinista que retorna una marca de tiempo inmutable, independizando la prueba del reloj del sistema.

¿Qué representa la Triangulación en TDD y en qué coyunturas resulta imperativa?

La triangulación radica en escribir dos o más casos de prueba con parámetros y resultados disímiles para justificar la generalización del algoritmo más allá de un valor literal predefinido. Es imperativa cuando la fórmula general no es evidente a priori, obligando al ingeniero a derivar la solución formal exclusivamente a partir de las aserciones de prueba.

¿Cuál es la diferencia entre aplicar el patrón Strategy y Chain of Responsibility en motores de tarificación?

Strategy selecciona una única implementación algorítmica para un tipo concreto de descuento (despacho polimórfico 1 a 1). Por su parte, Chain of Responsibility estructura una canalización secuencial donde el estado del carrito transita a través de múltiples evaluadores, deduciendo importes progresivamente y comprobando criterios de parada.

¿Cómo se previenen discrepancias de redondeo al repartir un descuento global entre diversos artículos del carrito?

Implementando el Método del Resto Mayor (Largest Remainder Method o Hare-Niemeyer). El descuento se divide inicialmente de forma entera con redondeo truncado (Math.floor). El remanente restante (en centavos) se adjudica a razón de 1 centavo por artículo ordenado de mayor a menor según su parte fraccionaria original, garantizando que la suma de las deducciones por línea coincida con exactitud con el descuento global.

¿Cómo debe estructurarse el testing guiado por pruebas de un analizador de lenguaje específico de dominio (DSL)?

Siguiendo una complejidad gramatical ascendente: 1) reconocimiento y tokenización de literales (números, identificadores); 2) operadores unarios; 3) operadores binarios con resolución de precedencia (multiplicación antes que suma); 4) subexpresiones entre paréntesis; 5) diagnóstico exhaustivo de errores de sintaxis con indicación de línea y columna.

¿Qué síntomas arquitectónicos indican que la lógica de cálculo está madura para refactorizarse en patrones?

Presencia de bifurcaciones repetitivas switch/if basadas en discriminantes de entidad a lo largo del módulo, métricas de complejidad ciclomática superiores a 10 en las rutinas de cálculo e imposibilidad de introducir una nueva regla sin alterar métodos ya probados (violación de OCP). Esta fase solo debe iniciarse con una cobertura de pruebas 100% verde.

TDD de Lógica de Negocio Pura: Modelado de Dominio Incremental desde Cero — Pruebas y Automatización QA

Fundamentos Arquitectónicos#

La lógica de dominio pura (Pure Domain Logic) constituye el núcleo esencial de cualquier aplicación empresarial, completamente aislada de dependencias de infraestructura, capas de persistencia, sockets de red y canalizaciones de renderizado de interfaz de usuario. En concordancia con los principios de Clean Architecture y Domain-Driven Design (DDD), el núcleo de dominio debe expresarse mediante funciones puras y deterministas o agregados inmutables.

Determinismo convierte a la lógica de negocio pura en el entorno idóneo para Test-Driven Development. La ausencia de operaciones de entrada/salida (I/O) permite ejecutar miles de especificaciones en milisegundos en memoria, verificando instantáneamente los invariantes del modelo de negocio.

En sistemas corporativos reales, las políticas de fijación de precios, liquidación de tarifas y reglas de cualificación de descuentos se vuelven progresivamente complejas. Sin una disciplina rigurosa de TDD, un motor de cálculo degenera velozmente en un entramado inmanejable de sentencias if-else y switch-case anidadas, donde incorporar una nueva regla comercial rompe invariantes límite previamente garantizados. TDD facilita la emergencia evolutiva de arquitecturas modulares y desacopladas (como los patrones Strategy o Chain of Responsibility) bajo la protección continua de especificaciones ejecutables automatizadas.

Modelo Mental#

El desarrollo de algoritmos de dominio mediante TDD sigue una trayectoria de diseño evolutivo: transiciona desde cálculos aritméticos elementales hacia una arquitectura desacoplada y componible de evaluación de reglas.

text

+-----------------------------------------------------------------------+
|                 PATRÓN DE EVOLUCIÓN DEL NÚCLEO DE DOMINIO             |
+-----------------------------------------------------------------------+
|                                                                       |
|   [Contexto de Entrada: Artículos del Carrito, Promociones, Reloj]    |
|                                 │                                     |
|                                 ▼                                     |
|              +-------------------------------------+                  |
|              | 1. Validación de Invariantes        |                  |
|              +-------------------------------------+                  |
|                                 │                                     |
|                                 ▼                                     |
|              +-------------------------------------+                  |
|              | 2. Cálculo del Subtotal Base        |                  |
|              +-------------------------------------+                  |
|                                 │                                     |
|                                 ▼                                     |
|              +-------------------------------------+                  |
|              | 3. Canalización de Estrategias      |                  |
|              | (Reglas: Fixed -> Percent -> Cap)   |                  |
|              +-------------------------------------+                  |
|                                 │                                     |
|                                 ▼                                     |
|   [Liquidación Final: Total en Centavos, Lista de Descuentos]         |
|                                                                       |
+-----------------------------------------------------------------------+

Invariantes Financieros en Código#

Al diseñar algoritmos monetarios, erradicar imprecisiones de coma flotante (estándar IEEE 754) es un imperativo categórico:

Regla 1: Todos los importes monetarios deben representarse como números enteros en la unidad mínima indivisible de la moneda (centavos, peniques, satoshis).
Regla 2: Toda función de cálculo recibe una abstracción de proveedor temporal inyectada (Clock), prohibiendo llamadas no deterministas directas a new Date().
Regla 3: Las estructuras de datos del dominio son estrictamente inmutables. Aplicar descuentos produce un nuevo contexto de liquidación sin mutar el estado del carrito original.

Aplicaciones en Producción#

Motores de Facturación SaaS: Liquidación de suscripciones con prorrateo (proration), tramos de precios por volumen (tiered pricing) y créditos personalizados de balance.
Plataformas de Comercio Electrónico y Marketplaces: Evaluación combinada de ofertas por lotes (2x1), cupones de importe fijo, acumulación de puntos de fidelidad y límites máximos porcentuales de descuento sobre el carrito.
Analizadores de Tarifas Logísticas: Cálculo de recargos por peso volumétrico, coeficientes de distancia por zonas geográficas y ventanas de entrega de mensajería.
Motores de Cotización y Suscripción Fintech: Determinación en tiempo real de tipos de interés, comisiones de estructuración y ajustes por perfil de riesgo crediticio.

Caso Práctico: Desarrollo Guiado por Pruebas de PricingEngine#

Abordemos un reto de ingeniería real: implementar de forma incremental un motor de cálculo de pedidos robusto, PricingEngine, capaz de procesar subtotales de artículos, cupones porcentuales, descuentos fijos, expiración temporal y un tope defensivo de deducción sobre el total de la cesta.

Paso 1: Cálculo Base y Verificación de Invariantes#

Iniciamos con nuestra prueba fallida inicial (RED): el motor debe computar con precisión la suma de los artículos válidos del carrito y rechazar inmediatamente precios unitarios negativos o cantidades iguales o inferiores a cero.

typescriptsrc/pricing/pricing-engine.spec.ts

import { describe, it, expect } from 'vitest';
import { PricingEngine, PricingError } from './pricing-engine';

describe('PricingEngine - Step 1: Base Calculation', () => {
  const defaultClock = () => new Date('2026-03-01T10:00:00Z');

  it('debe calcular con precisión el costo base para artículos válidos', () => {
    const engine = new PricingEngine(defaultClock);

    const result = engine.calculate({
      items: [
        { productId: 'item-1', unitPriceCents: 1000, quantity: 2 }, // 2000 centavos
        { productId: 'item-2', unitPriceCents: 500, quantity: 1 },  // 500 centavos
      ],
      promotions: [],
    });

    expect(result.subtotalCents).toBe(2500);
    expect(result.totalCents).toBe(2500);
    expect(result.discountCents).toBe(0);
  });

  it('debe lanzar PricingError ante precios negativos o cantidades no positivas', () => {
    const engine = new PricingEngine(defaultClock);

    expect(() =>
      engine.calculate({
        items: [{ productId: 'item-1', unitPriceCents: -100, quantity: 1 }],
        promotions: [],
      })
    ).toThrow(PricingError);
  });
});

Implementamos el código mínimo imprescindible para satisfacer las pruebas (GREEN).

typescriptsrc/pricing/pricing-engine.ts

export class PricingError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'PricingError';
  }
}

export interface CartItem {
  readonly productId: string;
  readonly unitPriceCents: number;
  readonly quantity: number;
}

export interface PricingCalculationResult {
  readonly subtotalCents: number;
  readonly discountCents: number;
  readonly totalCents: number;
}

export interface PricingContext {
  readonly items: readonly CartItem[];
  readonly promotions: readonly unknown[];
}

export class PricingEngine {
  constructor(private readonly clock: () => Date) {}

  public calculate(context: PricingContext): PricingCalculationResult {
    let subtotalCents = 0;

    for (const item of context.items) {
      if (item.unitPriceCents < 0 || item.quantity <= 0) {
        throw new PricingError('Invalid item price or quantity');
      }
      subtotalCents += item.unitPriceCents * item.quantity;
    }

    return {
      subtotalCents,
      discountCents: 0,
      totalCents: subtotalCents,
    };
  }
}

La suite de pruebas del Paso 1 se ejecuta satisfactoriamente (PASS).

Paso 2: Promociones Porcentuales y Fijas con Validación Temporal#

Formulamos los requisitos de las promociones comerciales:

Deducción porcentual sobre el subtotal (p. ej., 10%).
Descuento fijo en valor absoluto (p. ej., 500 centavos).
Cualquier cupón vencido debe descartarse si la fecha actual sobrepasa validUntil.

typescriptsrc/pricing/pricing-engine.spec.ts

describe('PricingEngine - Step 2: Promotions & Date Validation', () => {
  const currentDate = new Date('2026-03-01T12:00:00Z');
  const clock = () => currentDate;

  it('debe aplicar correctamente promociones de porcentaje válidas', () => {
    const engine = new PricingEngine(clock);

    const result = engine.calculate({
      items: [{ productId: 'item-1', unitPriceCents: 10000, quantity: 1 }],
      promotions: [
        {
          code: 'SPRING10',
          type: 'PERCENTAGE',
          value: 10,
          validUntil: new Date('2026-04-01T00:00:00Z'),
        },
      ],
    });

    expect(result.subtotalCents).toBe(10000);
    expect(result.discountCents).toBe(1000);
    expect(result.totalCents).toBe(9000);
  });

  it('debe ignorar promociones cuya fecha de vigencia haya expirado', () => {
    const engine = new PricingEngine(clock);

    const result = engine.calculate({
      items: [{ productId: 'item-1', unitPriceCents: 10000, quantity: 1 }],
      promotions: [
        {
          code: 'EXPIRED',
          type: 'FIXED',
          value: 2000,
          validUntil: new Date('2026-02-01T00:00:00Z'), // Expiró hace un mes
        },
      ],
    });

    expect(result.discountCents).toBe(0);
    expect(result.totalCents).toBe(10000);
  });
});

La prueba falla (FAIL). Actualizamos el modelo de dominio para alcanzar la fase GREEN.

typescriptsrc/pricing/pricing-engine.ts

export interface PercentagePromotion {
  readonly code: string;
  readonly type: 'PERCENTAGE';
  readonly value: number; // 0 - 100
  readonly validUntil: Date;
}

export interface FixedPromotion {
  readonly code: string;
  readonly type: 'FIXED';
  readonly value: number; // En centavos
  readonly validUntil: Date;
}

export type Promotion = PercentagePromotion | FixedPromotion;

export interface PricingContext {
  readonly items: readonly CartItem[];
  readonly promotions: readonly Promotion[];
}

export class PricingEngine {
  constructor(private readonly clock: () => Date) {}

  public calculate(context: PricingContext): PricingCalculationResult {
    let subtotalCents = 0;
    for (const item of context.items) {
      if (item.unitPriceCents < 0 || item.quantity <= 0) {
        throw new PricingError('Invalid item price or quantity');
      }
      subtotalCents += item.unitPriceCents * item.quantity;
    }

    const now = this.clock();
    let totalDiscountCents = 0;

    for (const promo of context.promotions) {
      if (promo.validUntil.getTime() < now.getTime()) {
        continue; // Cupón vencido
      }

      if (promo.type === 'PERCENTAGE') {
        const discount = Math.round((subtotalCents * promo.value) / 100);
        totalDiscountCents += discount;
      } else if (promo.type === 'FIXED') {
        totalDiscountCents += promo.value;
      }
    }

    const totalCents = Math.max(0, subtotalCents - totalDiscountCents);

    return {
      subtotalCents,
      discountCents: totalDiscountCents,
      totalCents,
    };
  }
}

Las cuatro especificaciones de los Pasos 1 y 2 concluyen con éxito (PASS).

Paso 3: Resolución de Conflictos y Límite Máximo Defensivo (Cap)#

Introducimos restricciones de negocio más rigurosas:

Tope de Descuento Defensivo (Cap): La deducción acumulada de descuentos jamás debe sobrepasar el 50% del subtotal del carrito.
Exclusividad Mutua: Prohibir la combinación de múltiples cupones porcentuales en una misma liquidación (lanzando PricingError).

typescriptsrc/pricing/pricing-engine.spec.ts

describe('PricingEngine - Step 3: Complex Rules & Caps', () => {
  const now = new Date('2026-03-01T12:00:00Z');
  const clock = () => now;

  it('debe restringir el descuento total al umbral defensivo del 50% del subtotal', () => {
    const engine = new PricingEngine(clock);

    const result = engine.calculate({
      items: [{ productId: 'item-1', unitPriceCents: 10000, quantity: 1 }], // 10000 centavos
      promotions: [
        {
          code: 'SUPERFIXED',
          type: 'FIXED',
          value: 8000, // Pretende deducir el 80%
          validUntil: new Date('2026-04-01T00:00:00Z'),
        },
      ],
    });

    expect(result.subtotalCents).toBe(10000);
    expect(result.discountCents).toBe(5000); // Limitado al 50%
    expect(result.totalCents).toBe(5000);
  });

  it('debe rechazar la presencia simultánea de múltiples promociones porcentuales', () => {
    const engine = new PricingEngine(clock);

    expect(() =>
      engine.calculate({
        items: [{ productId: 'item-1', unitPriceCents: 10000, quantity: 1 }],
        promotions: [
          {
            code: 'SALE10',
            type: 'PERCENTAGE',
            value: 10,
            validUntil: new Date('2026-04-01T00:00:00Z'),
          },
          {
            code: 'SALE20',
            type: 'PERCENTAGE',
            value: 20,
            validUntil: new Date('2026-04-01T00:00:00Z'),
          },
        ],
      })
    ).toThrow('Multiple percentage promotions are not allowed');
  });
});

Las pruebas fallan. Incorporamos la lógica correspondiente en el motor:

typescriptsrc/pricing/pricing-engine.ts

public calculate(context: PricingContext): PricingCalculationResult {
  let subtotalCents = 0;
  for (const item of context.items) {
    if (item.unitPriceCents < 0 || item.quantity <= 0) {
      throw new PricingError('Invalid item price or quantity');
    }
    subtotalCents += item.unitPriceCents * item.quantity;
  }

  const now = this.clock();
  let percentagePromosCount = 0;

  for (const promo of context.promotions) {
    if (promo.type === 'PERCENTAGE') {
      percentagePromosCount++;
    }
  }

  if (percentagePromosCount > 1) {
    throw new PricingError('Multiple percentage promotions are not allowed');
  }

  let rawDiscountCents = 0;

  for (const promo of context.promotions) {
    if (promo.validUntil.getTime() < now.getTime()) {
      continue;
    }

    if (promo.type === 'PERCENTAGE') {
      rawDiscountCents += Math.round((subtotalCents * promo.value) / 100);
    } else if (promo.type === 'FIXED') {
      rawDiscountCents += promo.value;
    }
  }

  // Límite de seguridad: máximo 50% del subtotal
  const maxAllowedDiscount = Math.floor(subtotalCents * 0.5);
  const finalDiscountCents = Math.min(rawDiscountCents, maxAllowedDiscount);
  const totalCents = subtotalCents - finalDiscountCents;

  return {
    subtotalCents,
    discountCents: finalDiscountCents,
    totalCents,
  };
}

Las 6 pruebas de los Pasos 1 a 3 están en verde (PASS).

Paso 4: Fase de REFACTOR — Patrón Strategy y Separación de Responsabilidades#

El código actual cumple con todas las expectativas funcionales, pero transgrede el Principio de Abierto/Cerrado (OCP): añadir un nuevo tipo de descuento requeriría editar directamente el método calculate. Llevamos a cabo una refactorización hacia una arquitectura polimórfica basada en el patrón Strategy bajo la protección de nuestros tests automatizados.

typescriptsrc/pricing/pricing-engine.ts

export class PricingError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'PricingError';
  }
}

export interface CartItem {
  readonly productId: string;
  readonly unitPriceCents: number;
  readonly quantity: number;
}

export interface PercentagePromotion {
  readonly code: string;
  readonly type: 'PERCENTAGE';
  readonly value: number;
  readonly validUntil: Date;
}

export interface FixedPromotion {
  readonly code: string;
  readonly type: 'FIXED';
  readonly value: number;
  readonly validUntil: Date;
}

export type Promotion = PercentagePromotion | FixedPromotion;

export interface PricingCalculationResult {
  readonly subtotalCents: number;
  readonly discountCents: number;
  readonly totalCents: number;
}

export interface PricingContext {
  readonly items: readonly CartItem[];
  readonly promotions: readonly Promotion[];
}

// 1. Contrato de la Estrategia de Descuento
export interface DiscountStrategy {
  calculateDiscount(subtotalCents: number, promo: Promotion, now: Date): number;
}

class PercentageDiscountStrategy implements DiscountStrategy {
  calculateDiscount(subtotalCents: number, promo: Promotion, now: Date): number {
    if (promo.type !== 'PERCENTAGE' || promo.validUntil.getTime() < now.getTime()) {
      return 0;
    }
    return Math.round((subtotalCents * promo.value) / 100);
  }
}

class FixedDiscountStrategy implements DiscountStrategy {
  calculateDiscount(subtotalCents: number, promo: Promotion, now: Date): number {
    if (promo.type !== 'FIXED' || promo.validUntil.getTime() < now.getTime()) {
      return 0;
    }
    return promo.value;
  }
}

// 2. Validador de Invariantes de Dominio
class PricingValidator {
  public static validate(context: PricingContext): void {
    for (const item of context.items) {
      if (item.unitPriceCents < 0 || item.quantity <= 0) {
        throw new PricingError('Invalid item price or quantity');
      }
    }

    const percentageCount = context.promotions.filter(
      (p) => p.type === 'PERCENTAGE'
    ).length;

    if (percentageCount > 1) {
      throw new PricingError('Multiple percentage promotions are not allowed');
    }
  }
}

// 3. Fachada del Motor de Cálculo
export class PricingEngine {
  private readonly strategies: ReadonlyMap<Promotion['type'], DiscountStrategy>;
  private static readonly MAX_DISCOUNT_RATIO = 0.5; // Tope del 50%

  constructor(private readonly clock: () => Date) {
    this.strategies = new Map<Promotion['type'], DiscountStrategy>([
      ['PERCENTAGE', new PercentageDiscountStrategy()],
      ['FIXED', new FixedDiscountStrategy()],
    ]);
  }

  public calculate(context: PricingContext): PricingCalculationResult {
    PricingValidator.validate(context);

    const subtotalCents = context.items.reduce(
      (sum, item) => sum + item.unitPriceCents * item.quantity,
      0
    );

    const now = this.clock();
    let accumulatedDiscountCents = 0;

    for (const promo of context.promotions) {
      const strategy = this.strategies.get(promo.type);
      if (strategy) {
        accumulatedDiscountCents += strategy.calculateDiscount(subtotalCents, promo, now);
      }
    }

    // Aplicación del tope de seguridad
    const maxDiscountAllowed = Math.floor(subtotalCents * PricingEngine.MAX_DISCOUNT_RATIO);
    const finalDiscountCents = Math.min(accumulatedDiscountCents, maxDiscountAllowed);
    const totalCents = Math.max(0, subtotalCents - finalDiscountCents);

    return {
      subtotalCents,
      discountCents: finalDiscountCents,
      totalCents,
    };
  }
}

La ejecución de Vitest certifica: el 100% de las pruebas se mantienen en verde. La estructura interna se ha modularizado, la validación se ha encapsulado y el polimorfismo se ha establecido sin necesidad de modificar ni una sola línea en las especificaciones existentes.

Errores Frecuentes#

Ошибка: Utilizar Números de Coma Flotante (Floats) para Operaciones Monetarias

Almacenar valores monetarios como números fraccionarios (19.99). La evaluación de 0.1 + 0.2 en JavaScript devuelve 0.30000000000000004. En sistemas financieros, este desfase causa acumulación de errores de redondeo e incongruencias contables. Utilice siempre unidades enteras menores (cents, minor units).

Ошибка: Acoplamiento Directo al Reloj del Sistema con new Date() en el Dominio

Llamar a const now = new Date() dentro de las rutinas de cálculo despoja a las pruebas de su determinismo. Un test que valide cupones por fecha de vigencia pasará hoy pero fallará de forma inesperada cuando expire la fecha objetivo. Inyecte invariablemente un proveedor de reloj clock: () => Date.

Ошибка: Mutación In Situ de Estructuras de Entrada (In-Place Mutation)

Modificar directamente los objetos del carrito recibidos (por ejemplo, asignando item.discountApplied = true). Esto induce efectos secundarios opacos en el árbol de componentes de React y arruina la predictibilidad del renderizado. Los métodos del dominio deben ser funciones puras que retornen instancias nuevas e inmutables.

Ошибка: Sobreingeniería Prematura de Patrones en el Paso 1

Intentar construir un interpretador abstracto de reglas basado en árboles AST desde la primera especificación. Escriba el código más simple y directo posible hasta que los requisitos de las pruebas evidencien duplicación y complejidad reales. La abstracción arquitectónica debe florecer de manera natural en la etapa de Refactor.

Ciclo Paso a Paso de Evolución del Algoritmo de Dominio#

Etapas en la Evolución de la Lógica de Dominio

Definición del Invariante Base

Redactar la prueba determinista más sencilla libre de efectos secundarios. Verificar límites de entrada (cantidades negativas, colecciones vacías).

Implementación Mínima Satisfactoria

Escribir lógica secuencial directa en una función hasta que las pruebas adquieran estado verde.

Triangulación de Reglas de Borde

Incorporar casos de prueba que cubran intervalos temporales, topes máximos (Caps) e incompatibilidad entre modificadores.

Extracción de Estrategias Polimórficas (Refactor)

Aislar bifurcaciones condicionales en clases de estrategia o funciones reductoras amparadas por la cobertura de pruebas.

Pruebas de Estrés Numérico y Redondeo

Examinar divisiones por cero, desbordamiento de enteros y exactitud estricta en el redondeo al centavo.

Preguntas de Entrevista#

Preguntas de entrevista7 preguntas

Temas Relacionados#

Temas relacionados

El Ciclo Red-Green-Refactor y el Modelo Mental de TDD— Fundamentos de la disciplina TDD, iteraciones con baby steps y las Tres Leyes del TDD.Escuelas de Chicago vs Londres en TDD— Agregados reales clasicistas frente a mocks en las fronteras de colaboración.Pruebas de Mutación con Stryker— Evaluación de la resiliencia y poder de detección de las pruebas mediante inyección de mutantes.