¿En qué se distingue un Sum Type de un Product Type?

Un Product Type (p. ej. { a: string; b: number }) almacena el valor A Y el valor B a la vez; su cardinalidad es el producto de las cardinalidades de sus campos. Un Sum Type (p. ej. Draft | Paid | Shipped) contiene el valor de EXACTAMENTE UNA de las variantes a la vez; su cardinalidad es la suma de sus casos. Juntos componen los tipos de datos algebraicos (ADT).

¿Qué son los Branded Types y qué problema atajan en TypeScript?

TypeScript aplica tipado estructural: tipos con idéntica conformación resultan indistinguibles para el compilador (type UserId = string y type OrderId = string son mutuamente asignables). Los Branded Types agregan una marca nominal invisible (string & Brand ), evitando que se trasladen IDs erróneos en firmas de funciones.

¿Por qué son indispensables los Smart Constructors?

Un Smart Constructor restringe la instanciación libre y canaliza la creación por una factoría supervisada (p. ej. makeEmail(str): Either ). Esto otorga la garantía absoluta de que toda instancia de Email en memoria satisface los axiomas de validación de negocio.

¿Cómo protege switch (order._tag) contra estados no atendidos tras un refactor?

Al sustentarse en uniones discriminadas, TypeScript despliega Control Flow Analysis. Si se agrega un nuevo estado (como RefundedOrder) y no se contempla en el switch, el análisis de exhaustividad sobre el caso default (casteo a never) originará un fallo estático de compilación.

¿Qué postula el principio 'Make Impossible States Impossible'?

Diseñar los tipos de forma que una disposición inconsistente o no contemplada por las reglas de negocio no pueda si quiera compilar. En lugar de flags como { isPaid: boolean, isShipped: boolean }, se emplean tipos mutuamente excluyentes (PaidOrder, ShippedOrder) donde campos como trackingNumber solo existen cuando procede.

¿Cómo difiere la igualdad estructural (Value Equality) de la igualdad referencial?

En JavaScript nativo los objetos se cotejan por su puntero de memoria (new Money(10) !== new Money(10)). En el modelado de dominio, los Value Objects son idénticos si sus propiedades coinciden. Data.Class y Equal.equals en Effect-TS proporcionan comparación estructural profunda de forma automática.

¿Por qué las transiciones de estado de dominio no deben realizar I/O ni logs?

Mezclar efectos colaterales (I/O) en las transiciones arruina el determinismo y la transparencia referencial. Una función pura (Order, Event) => Either se prueba en milisegundos sin mocks, se ejecuta bajo transacciones atómicas y se almacena en Event Sourcing. Las operaciones secundarias residen en la capa de orquestación.

Modelado puro de dominio: tipos algebraicos (ADT) y validación — Dominio de TypeScript 5.8+

Base arquitectónica#

En el enfoque clásico orientado a objetos de Domain-Driven Design (DDD), las entidades de dominio suelen modelarse como clases con estado interno mutable, getters, setters y efectos secundarios encubiertos.

Este patrón origina vulnerabilidades críticas en la lógica de negocio:

Representación de estados inválidos (Illegal States): Modelos con abundancia de campos opcionales permiten que una entidad subsista en formas inconsistentes (como un pedido en estado Shipped sin fecha de expedición ni código de seguimiento).
Obsesión por los tipos primitivos (Primitive Obsession): Usar tipos básicos string y number para identificadores, importes monetarios y emails conduce a traspapelar accidentalmente userId en lugar de orderId al invocar funciones.
Pérdida de transparencia referencial (Broken Referential Transparency): La mutación por referencia imposibilita rastrear el linaje de cambios, auditar transiciones y efectuar un almacenamiento en caché determinista.

La arquitectura funcional resuelve estas carencias mediante tipos de datos algebraicos (Algebraic Data Types, ADT) y la máxima: Make Impossible States Impossible (Haz que los estados inválidos sean irrepresentables).

En combinación con el patrón Smart Constructors (Constructores inteligentes), la lógica de dominio se vuelve puramente determinista, aislada de I/O y formalmente verificada por el compilador estático.

Modelo mental#

En el modelado funcional, las estructuras se dividen en tipos producto (Y) y tipos suma (O):

text

+-------------------------------------------------------------------------+
|                  SISTEMA DE TIPOS ALGEBRAICO DEL DOMINIO (ADT)          |
+-------------------------------------------------------------------------+
| 1. PRODUCT TYPE (Tipo producto): El pedido contiene ID Y User Y Items   |
|    type OrderHeader = { readonly id: OrderId; readonly user: UserId }   |
+-------------------------------------------------------------------------+
                                     |
                                     +---> Composición
                                     |
+-------------------------------------------------------------------------+
| 2. SUM TYPE (Tipo suma): El pedido reside en UNO de los estados         |
|                          mutuamente excluyentes:                        |
|    type OrderState =                                                    |
|      | DraftOrder     (Items, Total)                                    |
|      | PaidOrder      (Items, Total, PaymentId, PaidAt)                 |
|      | ShippedOrder   (Items, Total, TrackingNumber, ShippedAt)         |
|      | CancelledOrder (Reason, CancelledAt)                             |
+-------------------------------------------------------------------------+

Un estado no válido resulta físicamente imposible de compilar: en DraftOrder, atributos como trackingNumber o paidAt no existen a nivel de tipos, suprimiendo de raíz errores lógicos en UI y servicios de backend.

Comparativa de modelos de dominio: OOP vs ADT Puro

Критерий	Clases OOP mutables con flags	ADTs puros + Smart Constructors
Mutabilidad	Mutaciones por asignación directa (order.status = 'PAID')	Inmutabilidad absoluta (la transición retorna un estado nuevo)
Estados inválidos	Posibles (order.isPaid=true pero paymentId=undefined)	Imposibles: el sistema de tipos rechaza combinaciones inconsistentes
Obsesión por primitivos	Identificadores representados como string/number crudos	Tipos nominales con Brand (OrderId, CurrencyCode)
Efectos secundarios	Los métodos ejecutan peticiones de red o base de datos	Reglas de negocio expresadas como funciones puras sin I/O

Aplicaciones prácticas#

Fintech y sistemas de facturación: Modelado de máquinas de estado en pasarelas de pago (Created -> Authorized -> Captured / Voided / Refunded) con verificación estricta de atributos por fase.
Logística y comercio electrónico: Garantizar que el despacho de mercancía (Shipping) no pueda invocarse antes de que la transacción haya sido capturada bancariamente.
Validación Zero-Trust de formularios: Transformación de cadenas de texto sin sanear en tipos de dominio convalidados (EmailAddress, IBAN, PositiveInteger) en la frontera del controlador.
Auditoría y Event Sourcing: Persistencia del historial de eventos como tipos suma inmutables (OrderEvent), asegurando la reconstrucción determinista del agregado.

Cómo funciona#

1. Tipos nominales (Branded Types) y Smart Constructors#

Para evitar confusiones entre primitivos idénticos empleamos tipado nominal mediante el módulo Brand de Effect-TS:

typescriptsrc/domain/primitives.ts

import { Brand, Either } from 'effect';

// 1. Declaración de tipos nominales (Branded Types)
export type Email = string & Brand.Brand<'Email'>;
export const Email = Brand.refined<Email>(
  (value) => value.includes('@') && value.length > 5,
  (value) => Brand.error(`La cadena "${value}" no constituye un correo válido`)
);

export type OrderId = string & Brand.Brand<'OrderId'>;
export const OrderId = Brand.nominal<OrderId>();

export type Cents = number & Brand.Brand<'Cents'>;
export const Cents = Brand.refined<Cents>(
  (value) => Number.isInteger(value) && value >= 0,
  (value) => Brand.error(`El importe ${value} debe ser un entero no negativo`)
);

// 2. Smart Constructor devolviendo Either
export class InvalidEmailError {
  readonly _tag = 'InvalidEmailError';
  constructor(readonly message: string) {}
}

export function makeEmail(rawString: string): Either.Either<InvalidEmailError, Email> {
  return Email.either(rawString).pipe(
    Either.mapLeft((brandErrors) => new InvalidEmailError(brandErrors[0].message))
  );
}

Ahora es inviable suministrar un string ordinario donde se exige Email: TypeScript emitirá Type 'string' is not assignable to type 'Email'.

2. Modelado de estados con tipos suma (Sum Types)#

Diseñamos el ciclo de vida de un pedido de modo que las combinaciones discordantes de campos no compilen:

typescriptsrc/domain/order.ts

import { Data } from 'effect';
import type { OrderId, Email, Cents } from './primitives';

export interface OrderItem {
  readonly sku: string;
  readonly quantity: number;
  readonly price: Cents;
}

// 1. Estados del pedido modelados con Data.TaggedClass
export class DraftOrder extends Data.TaggedClass('DraftOrder')<{
  readonly id: OrderId;
  readonly customerEmail: Email;
  readonly items: readonly OrderItem[];
  readonly total: Cents;
}> {}

export class PaidOrder extends Data.TaggedClass('PaidOrder')<{
  readonly id: OrderId;
  readonly customerEmail: Email;
  readonly items: readonly OrderItem[];
  readonly total: Cents;
  readonly paymentTransactionId: string;
  readonly paidAt: Date;
}> {}

export class ShippedOrder extends Data.TaggedClass('ShippedOrder')<{
  readonly id: OrderId;
  readonly customerEmail: Email;
  readonly items: readonly OrderItem[];
  readonly total: Cents;
  readonly paymentTransactionId: string;
  readonly trackingNumber: string;
  readonly shippedAt: Date;
}> {}

export class CancelledOrder extends Data.TaggedClass('CancelledOrder')<{
  readonly id: OrderId;
  readonly reason: string;
  readonly cancelledAt: Date;
}> {}

// Tipo suma algebraico de todos los estados admisibles
export type Order = DraftOrder | PaidOrder | ShippedOrder | CancelledOrder;

3. Transiciones de estado puras de dominio#

La lógica de negocio se escribe como funciones puras que reciben el estado vigente y devuelven el estado subsiguiente o un error tipado:

typescriptsrc/domain/transitions.ts

import { Either } from 'effect';
import {
  type Order,
  DraftOrder,
  PaidOrder,
  ShippedOrder,
  CancelledOrder,
} from './order';

export class OrderTransitionError {
  readonly _tag = 'OrderTransitionError';
  constructor(readonly message: string) {}
}

// 1. Pagar pedido: admisible ÚNICAMENTE desde DraftOrder
export function payOrder(
  order: Order,
  paymentTransactionId: string
): Either.Either<OrderTransitionError, PaidOrder> {
  switch (order._tag) {
    case 'DraftOrder':
      return Either.right(
        new PaidOrder({
          id: order.id,
          customerEmail: order.customerEmail,
          items: order.items,
          total: order.total,
          paymentTransactionId,
          paidAt: new Date(),
        })
      );
    case 'PaidOrder':
      return Either.left(new OrderTransitionError('El pedido ya ha sido pagado'));
    case 'ShippedOrder':
      return Either.left(new OrderTransitionError('El pedido ya ha sido enviado'));
    case 'CancelledOrder':
      return Either.left(new OrderTransitionError('No se puede pagar un pedido cancelado'));
  }
}

// 2. Enviar pedido: admisible ÚNICAMENTE desde PaidOrder
export function shipOrder(
  order: Order,
  trackingNumber: string
): Either.Either<OrderTransitionError, ShippedOrder> {
  if (order._tag !== 'PaidOrder') {
    return Either.left(
      new OrderTransitionError(
        `Despacho denegado: el pedido se halla en estado ${order._tag}, no en PaidOrder`
      )
    );
  }

  return Either.right(
    new ShippedOrder({
      id: order.id,
      customerEmail: order.customerEmail,
      items: order.items,
      total: order.total,
      paymentTransactionId: order.paymentTransactionId,
      trackingNumber,
      shippedAt: new Date(),
    })
  );
}

Canalización de arquitectura

Ciclo de vida de una transición de dominio pura sin efectos secundarios

4 etapas

Validación de entrada vía Smart Constructors

Smart ConstructorsNúcleo / Sistema

Conversión de primitivos en tipos nominales Email, Cents. Bloqueo de entradas malformadas.

Artefactos:Email BrandCents Brand

Creación del estado inicial (DraftOrder)

Domain EntityPlantilla / UI

Instanciación de la entidad inmutable DraftOrder con atributos requeridos completos.

Artefactos:DraftOrder Instance

Transición pura payOrder(draft, txnId)

Pure TransitionNúcleo / Sistema

Cálculo del nuevo estado PaidOrder preservando la inmutabilidad del draft previo (Transparencia referencial).

Artefactos:PaidOrder Instance

Matching exhaustivo de estados

Pattern MatchingNúcleo / Sistema

TypeScript verifica que todas las ramas del ADT Order hayan sido tratadas.

Artefactos:Guaranteed State Safety

Artefacto de producción: Objetos de valor con igualdad estructural (Data.Class)#

A continuación se muestra un Value Object con igualdad por contenido empleando Data.Class y Equal.equals de Effect-TS:

Production Artifactsrc/domain/valueObjects.ts

Modelado de Value Objects con soporte nativo de comparación estructural Equal.equals y seguridad estricta de tipos.

typescript

import { Data, Equal } from 'effect';
import type { Cents } from './primitives';

export interface MoneyProps {
  readonly amount: Cents;
  readonly currency: 'USD' | 'EUR' | 'GBP';
}

// Clase Money con igualdad estructural automática por valor (Value Object)
export class Money extends Data.Class<MoneyProps> {
  public add(other: Money): Money {
    if (this.currency !== other.currency) {
      throw new Error(`Discrepancia de monedas: ${this.currency} y ${other.currency}`);
    }
    return new Money({
      amount: ((this.amount + other.amount) as unknown) as Cents,
      currency: this.currency,
    });
  }
}

// Demostración de igualdad estructural:
// Dos instancias independientes en memoria con atributos idénticos resultan iguales
export function compareMoney(m1: Money, m2: Money): boolean {
  // En JS estándar: m1 === m2 retorna false (punteros de memoria distintos)
  // En Effect: Equal.equals(m1, m2) retorna true (igualdad estructural de valor)
  return Equal.equals(m1, m2);
}

Errores comunes (Pitfalls)#

Ошибка: Infierno de propiedades opcionales en vez de Sum Types

Agrupar todas las etapas de una entidad en una sola interfaz colmada de campos opcionales fuerza el uso sistemático de aserciones no nulas inseguras (!).

typescript

// ❌ Antipatrón: campos opcionales permiten estados absurdos
interface FlawedOrder {
  status: 'draft' | 'paid' | 'shipped';
  paymentTransactionId?: string; // ¿Olvidado al marcar 'paid'? ¡El compilador no avisa!
  trackingNumber?: string;       // ¿Informado en estado 'draft'? ¡Corrupción en runtime!
}

// ✅ Solución correcta: tipo suma algebraico (DraftOrder | PaidOrder | ShippedOrder)

Ошибка: Evadir el constructor inteligente mediante casting directo (as Brand)

Forzar el tipo con const email = "invalido" as Email subvierte los mecanismos de validación instituidos en el constructor inteligente. Solución: vetar aserciones directas con el linter (@typescript-eslint/consistent-type-assertions) y publicar exclusivamente constructores make*.

Ошибка: Insertar llamadas de red dentro de funciones de transición de dominio

Despachar correos o consultar bases de datos desde payOrder contamina la pureza del modelo, lastra los tests y menoscaba el determinismo. Solución: la función de dominio solo computa el nuevo estado; la orquestación I/O compete a la capa exterior de servicios de aplicación.

Algoritmo paso a paso para modelar el dominio#

Diseño de un dominio funcional

Auditoría de primitivos y creación de BrandNominal Types

Identificar claves de negocio (UserId, OrderId, Money) y blindarlas con tipos nominales Brand.

Implementación de Smart ConstructorsConstructors

Elaborar factorías make* que retornen Either<ValidationError, BrandedType>.

Descomposición de estados en tipos sumaSum Types

Tipar cada estado de ciclo de vida con un Data.TaggedClass desprovisto de campos opcionales.

Codificación de transiciones purasState Transitions

Escribir reglas de negocio como funciones deterministas: (State, Event) => Either<Error, NewState>.

Conexión con la capa de aplicaciónOrchestration

Integrar el dominio puro con la persistencia y la red mediante Application Services en Effect-TS.

Preguntas de entrevista#

Preguntas de entrevista7 preguntas

Temas relacionados#

Temas relacionados

Patrón Option y Either (Result)— Contenedores funcionales esenciales para tratamiento tipado de errores.Arquitectura de Effect-TS: modelo mental del tipo Effect— Conceptos esenciales y canales de cómputo en Effect.Gestión de dependencias en Effect: Context.Tag y Layer— Inyección de dependencias y arquitectura de capas en Effect-TS.