El modelo de dominio es una forma de organizar la lógica de negocio aprovechando la programación orientada a objetos al 100%, combinando datos y comportamiento en una misma entidad. Si vienes del script de transacción, vas a notar enseguida la diferencia: tus objetos dejan de ser cascarones vacíos y empiezan a hacer cosas útiles por sí mismos.

¿Qué problema resuelve el modelo de dominio frente al script de transacción?

El script de transacción tiene una limitación grande: no usa POO de forma apropiada. Termina produciendo lo que se conoce como modelos anémicos.

Un modelo anémico ocurre cuando tienes objetos partidos en dos mundos:

• Objetos con comportamiento (métodos) pero sin datos propios.
• Objetos con datos (atributos) pero sin ningún comportamiento.
• Servicios enormes con métodos llenos de instrucciones secuenciales.

Es una POO a medias. Y aquí entra el modelo de dominio: representa el negocio con objetos que tienen al mismo tiempo datos y comportamiento, lo cual abre la puerta a soluciones mucho más expresivas y reutilizables.

¿Qué es un modelo anémico? Es un objeto que solo guarda datos o solo ejecuta métodos, pero no ambos. Resultado: la lógica termina dispersa en servicios y los objetos pierden valor.

¿En qué se diferencia un modelo de dominio de un modelo de base de datos?

Aquí hay una confusión muy frecuente que conviene aclarar de entrada. No son lo mismo, aunque a veces se vean parecidos.

Imagina una clase Producto en C# decorada con configuración de Entity Framework: campos requeridos, llave primaria, llave foránea, validaciones de longitud. Eso no es modelo de dominio. Es una clase ligada a la persistencia, y su lugar natural es la capa de infraestructura, no el dominio.

El modelo de dominio describe el negocio. El modelo de base de datos describe cómo se almacenan los datos. Mezclarlos es una de las primeras señales de que algo se está saliendo de su capa.

¿Qué elementos puede incluir un modelo de dominio bien construido?

Cuando aprovechas la POO de verdad, tu dominio puede contener piezas con roles muy distintos.

• Entidades: el insumo principal, con identidad propia.
• Objetos de valor: agrupan datos sin tener identidad.
• Herencia: una clase extiende a otra para añadir comportamiento especializado.
• Relaciones: conexiones entre entidades o con otros objetos.
• Patrones de diseño: estructuras reutilizables que combinan herencia y relaciones para resolver problemas más complejos.

Con estos bloques puedes modelar reglas de negocio que en un script de transacción terminarían siendo if dentro de if dentro de un método interminable.

¿Cómo se ve una entidad rica en un modelo de dominio?

Volviendo al ejemplo del vuelo, la entidad Flight deja de ser una bolsa de propiedades y empieza a tener métodos con sentido.

• AddBooking: agrega una reservación y actualiza dinámicamente los asientos disponibles según los pasajeros.
• IsAvailable: verifica si hay sillas suficientes para el número de pasajeros que quieres revisar.
• Relación con Booking: el vuelo mantiene su listado de reservas.
• Relación con Route: agrupa información del trayecto.

La lógica vive donde están los datos. Eso es lo que vuelve cohesionado al objeto.

¿Qué es un objeto de valor y cuándo conviene usarlo?

La Route del ejemplo es un value object. No tiene identidad propia y no necesariamente existe como tabla en la base de datos. Su trabajo es agrupar datos y operaciones que naturalmente van juntos.

En este caso, la ruta contiene dos strings, origen y destino, y un método para validar si la ruta tiene sentido: por ejemplo, que ninguno esté vacío o que origen y destino no sean iguales.

¿Qué es un objeto de valor? Es un objeto sin identidad que agrupa datos y comportamiento relacionados. El ejemplo clásico es un string: un conjunto de caracteres con operaciones aplicables sobre ellos.

El beneficio práctico: dejas de tener atributos sueltos repartidos por toda la aplicación y los encapsulas en una pieza con reglas propias.

¿Cómo cambia la capa de servicios al adoptar modelo de dominio?

El servicio se vuelve más liviano. En el método de búsqueda, por ejemplo, ya no validas la ruta dentro del servicio: se la pides a la propia ruta. Tampoco preguntas a mano si el vuelo tiene cupo: llamas a IsAvailable del vuelo.

Esto cambia el reparto de responsabilidades:

1. El servicio orquesta y delega.
2. Las entidades ejecutan las reglas que les pertenecen.
3. Los objetos de valor protegen la coherencia de sus datos.

El resultado es una aplicación con mayor reutilización y una POO más cohesionada, donde los objetos cargan con el peso de las reglas y los servicios dejan de ser monolitos. Y aquí viene lo interesante: este enfoque conecta directo con la capa de servicios, que es el complemento natural del modelo de dominio.

¿Cómo organizas hoy tu lógica de negocio: en scripts de transacción o ya estás migrando a modelos de dominio? Cuéntame en los comentarios.