E096_Lenguaje ubícuo. Diseño (de software) Dirigido por Dominios

Buenas, esto es BIMPRAXIS, el podcast donde el

BIM se encuentra con la inteligencia artificial.

Exploramos la ciencia, la tecnología y el futuro

desde el enfoque de la arquitectura, ingeniería y

construcción.

¡Empezamos!

Muy buenas, bienvenidas, bienvenidos a un nuevo episodio

de BIMPRAXIS.

Hoy os traemos el diseño guiado por el

dominio.

¿Cómo domar la complejidad en el corazón del

software?

Hola a todos.

Y, bueno, hoy vamos a sumergirnos en un

problema que, a ver, seamos completamente sinceros, es

algo que persigue como un fantasma a casi

cualquier equipo técnico en algún momento de su

existencia.

Totalmente.

A todos nos ha pasado.

Es que, imaginad la situación.

Empezáis un proyecto, todo es optimismo, los diagramas

en la pizarra están limpios, la arquitectura parece

impecable y, de repente… Pasan un par de

años y es un monstruo.

Exacto, un monstruo implacable.

Hablamos de un código incompatible.

Incomprensible, extremadamente rígido, donde vas y cambias una

simple coma para, no sé, añadir una función

minúscula, y misteriosamente se rompen tres cosas distintas

en otra parte del sistema.

¡Qué locura!

Pero es el pan de cada día, ¿verdad?

Para hoy es fascinante.

Porque casi nunca es por falta de habilidades

técnicas o porque los programadores no sepan teclear.

Vamos.

Claro, no es eso.

Es porque el código, en algún punto oscuro

del camino, se ha desconectado por completo de

la realidad viva, palpitante del negocio que intentaba

modelar.

Así que vamos a explorar a fondo el

legendario enfoque de Eric Evans, conocido mundialmente como

el Domain Driven Design, o, bueno, diseño guiado

por el dominio.

Y el planteamiento de ese problema que haces

es fundamental.

Porque, a ver, el objetivo de nuestro análisis

a fondo de hoy no es aprender un

nuevo truco para picar código más rápido.

Ya, no venimos a eso.

Ni vamos a hablar de dominar el último

framework que se ha puesto de moda esta

semana, que siempre hay uno nuevo.

Hoy venimos a aprender a pensar sobre el

software de una manera radicalmente distinta.

A pensar, exacto.

La misión de esta exploración es, digamos, descubrir

cómo los equipos puramente técnicos y los verdaderos

expertos del negocio pueden llegar a fusionar sus

mentes.

Qué bien suena eso.

Sí, es decir, cómo pueden destilar lo que

en este ámbito llamamos un modelo profundo.

Para coger toda esa complejidad caótica, confusa y

desordenada del mundo real y convertirla en un

sistema de software, que sea de verdad flexible,

resistente al paso del tiempo y excepcionalmente poderoso.

Pues vamos a desgranar esto paso a paso.

Porque, para resolver el problema de ese software

caótico que acaba, pues, pudriéndose, primero tenemos que

entender cómo demonios se captura el conocimiento en

un proyecto.

Esa es la clave.

Históricamente, la inercia de la industria era muy

simple.

Tú te sientas con el cliente, le pides

que te dicte una lista de requisitos o

de funcionabilidades y te pones a programar como

si no hubiera un mañana.

La famosa lista de la compra, sí.

Exacto.

Pero aquí vemos que eso es una receta

garantizada para el desastre.

No podemos simplemente pedir esa lista.

Tenemos que hacer un esfuerzo activo que, bueno,

Evans denomina el triturado de conocimiento.

El knowledge crunching.

Y fíjate que el concepto del triturado de

conocimiento rompe totalmente con la idea pasiva del

programador.

Ese programador visto como un mero transcriptor.

Ya, el que solo toma notas.

Eso es.

Y para ilustrar cómo funciona.

Y para ilustrar cómo funciona esto en la

realidad, el texto nos sumerge en una anécdota

muy reveladora sobre el diseño de una herramienta

de software para placas de circuito impreso.

Los típicos PCBs de la electrónica.

Los de toda la vida, sí.

Los que llevan todos nuestros aparatos.

Pues a ver, el desarrollador de software asignado

al proyecto no sabía absolutamente nada de ingeniería

eléctrica.

Cero.

Su conocimiento era cero.

Cero patatero.

Y como era de esperar, pues las primeras

reuniones conjuntas fueron un desastre absoluto.

Me lo puedo imaginar, claro.

Los ingenieros de hardware estaban frustrados, intentaban explicar

lo que necesitaban, pero claro, para hacerse entender

por el informático, terminaban pidiendo funciones aburridísimas y

mecánicas de bases de datos.

O sea, bajando al barro técnico.

Exacto.

Decían cosas como, necesito que el programa lea

este archivo de texto inmenso, que ordene las

filas por este parámetro y escupa un informe

en pantalla.

Claro.

Lo que estaba ocurriendo ahí es un clásico.

Los ingenieros de hardware estaban...

Estaban intentando hacer el trabajo de diseño de

software por el programador.

Totalmente.

Editaban operaciones de datos y, a su vez,

pues el programador intentaba asimilar años de ingeniería

eléctrica de golpe.

Un caos absoluto donde al final nadie aportaba

su verdadero valor.

Y el proyecto se habría estancado ahí de

no ser por un punto de inflexión que

fue crucial.

Dejaron de hablar en abstracto.

¿Vale?

Dejaron de pasarse listas de funciones y se

pusieron frente a una pizarra a dibujar diagramas

juntos.

El momento mágico de la pizarra.

Siempre funciona.

El desarrollador empezó a esbozar cajas, líneas, intentando

representar el problema físico real y, de repente,

de todo ese torrente de jerga incomprensible, lograron

extraer un concepto clave.

¿Cuál fue?

Pues los ingenieros de hardware hablaban constantemente de

algo que llamaban NETS, que son, esencialmente, las

redes físicas de conductores que conectan los distintos

componentes en la placa.

Ah, vale, las redes.

Y también hablaban de HOPS, que son los

saltos individuales, de un punto a otro.

El problema real de los ingenieros era detectar

retrasos críticos en las señales si había demasiados

saltos en una red.

Claro, claro.

Al dibujar esto en la pizarra y darle

un nombre concreto a esas ideas, extrajeron oro

puro de toda esa maraña de información técnica.

Y eso es exactamente el triturado de conocimiento.

O sea, no es tomar notas.

No es tomar notas al dictado en una

reunión.

Es sondear.

Es masticar la información.

Probar ideas equivocadas incluso.

Y destilar un modelo conceptual hasta que tenga

perfecto sentido para ambas partes.

Aquí es donde se pone muy interesante.

Paremos un momento a analizar esto.

Porque, a ver, una vez que consigues ese

concepto brillante en la pizarra, te enfrentas al

problema del día a día, a la comunicación

real durante los meses que dura el desarrollo.

Ya, eso es otra historia.

En la gran mayoría de los proyectos, vivimos

atrapados en una especie de teléfono escacharrado permanente.

¡Qué gran verdad!

Es que es como pedir comida a domicilio

con su jerga legal.

Si el cliente llama y dice, no sé,

deseo anular el contrato de abastecimiento.

¡Madre mía!

Claro, el restaurante no sabe si tiene que

cancelar el pedido de patatas fritas o si

tiene que despedir a su proveedor de carne,

¿sabes?

Claro, claro.

Esa traducción intermedia es el lugar oscuro donde

los errores y los bugs se esconden y

se reproducen a sus anchas.

Los expertos de negocio hablan su jerga logística

o financiera en sus reuniones.

Sí.

Luego llegan los analistas de sistemas que lo

traducen a su propia jerga de diagramas funcionales

y finalmente los programadores cogen ese documento y

lo vuelven a traducir a su jerga técnica.

Hablar de tablas.

Tablas de bases de datos, variables string, bucles

for, es una locura.

Es una locura, sí.

Y el riesgo de esa traducción intermedia es

que los fallos del modelo conceptual quedan completamente

ocultos bajo unas capas inmensas de malentendidos.

Ya te digo.

Si cada estrato del equipo habla su propio

idioma, pues nadie se da cuenta de que

en realidad no se están entendiendo en absoluto

y no se dan cuenta hasta que el

software se despliega en producción.

Y bueno, fracasas trepitosamente.

El peor momento posible.

Exacto.

Así que la solución que propone el diseño

guiado por el dominio para aniquilar este teléfono

escacharrado es la instauración de lo que se

conoce como el lenguaje Ubiquo, el Ubiquus Language.

Eso es.

Y la regla aquí es estricta y radical.

Tiene que haber un idioma único.

Un solo idioma.

Un vocabulario que se construye basándose estrictamente en

ese modelo de dominio que el equipo ha

destilado en la pizarra, ¿no?

Y ese vocabulario se debe usar de forma

implacable e innegociable en todas partes.

En todas partes.

En las conversaciones de pasillo, en los documentos

técnicos, en las reuniones con el cliente y

lo que es infinitamente más crítico en el

propio código fuente.

A ver, vamos a desgranar esto poniéndonos un

poco en la piel de un equipo real,

porque es muy fácil decir.

Hablemos todos el mismo idioma, pero es como

intentar construir un edificio donde el arquitecto habla

francés, el capataz japonés y solo se comunican

mediante dibujos abstractos.

Ya, es complicado.

Pero ¿acaso no es natural que los expertos

en negocio usen su jerga y los programadores

la suya?

O sea, romper con los hábitos de un

programador que lleva diez años hablando de bases

de datos para forzar un único idioma parece

una tarea titánica.

¿Por qué forzarlo tanto?

Porque la sobrecarga de la traducción, como decíamos,

oculta los fallos.

Fíjate en la diferencia abismal de claridad con

un ejemplo real que recogen los textos.

Está centrado en el desarrollo de un sistema

para una agencia de transporte de mercancías.

El famoso cargo router.

Exacto, el cargo router.

Pues vamos a comparar dos formas de afrontar

la misma petición.

En el escenario tradicional de toda la vida,

el usuario del negocio dice oye, si cambia

la política de la aduana en un puerto,

hay que rehacer la ruta del cargamento.

Vale, lógico.

Y el programador, pensando en su mundo técnico,

responde vale, si ocurre ese evento, pues borraré

las filas correspondientes en la tabla de la

base de datos del MIOS y le pasaré

los datos al servicio de backend para que

la vuelva a poblar con la nueva información.

Uf, me duele la cabeza solo de visualizar

esa conversación.

Es terrible.

Están físicamente en la misma sala, pero habitan

universos conceptuales totalmente distintos.

O sea, si el negocio pide un cambio

sutil sobre cómo funciona la aduana, el programador

va a estar pensando en índices de tablas

en lugar de pensar en barcos y en

contenedores.

Exactamente.

Y ahora imagina la segunda conversación, donde el

equipo ya ha implementado un lenguaje ubicua riguroso.

A ver, el usuario dice exactamente lo mismo

sobre la aduana y el programador responde usando

el modelo y dice entendido, si cambias algún

atributo en la especificación de la ruta, comprobaremos

si el itinerario actual todavía la satisface.

Ajá.

Si no la satisface, generaremos un nuevo itinerario.

Ostras, qué diferencia.

Fíjate en el cambio de paradigma.

Ambos están utilizando conceptos concretos y compartidos.

Hablan de especificaciones de ruta y de itinerarios.

Ya no hay filas.

Ya no hay filas que se borran ni

tablas que se pueblan.

Nada de eso.

Si el modelo conceptual tiene un fallo lógico,

salta a la vista inmediatamente durante la charla,

porque ambos están usando las mismas palabras.

Claro, es transparente.

Y la magia reside en que si un

nuevo desarrollador abre el código, al día siguiente

no verá variables genéricas.

Va a haber clases y métodos que se

llaman literalmente especificación de ruta e itinerario.

Vale, vale, entiendo el inmenso valor de esto.

Lograr hablar el mismo idioma en una sala

de reuniones frente a un café, pues es

un triunfo.

Pero la realidad es tozuda.

Sí lo es.

Si ese modelo conceptual tan puro del que

hablas no se traduce de forma literal, directa

y sin fricciones al código, pues todo el

esfuerzo de la pizarra no sirve absolutamente para

nada, para nada.

Y esto, fíjate, nos abre la puerta a

un debate bastante candente en nuestra exploración de

hoy.

Esa unión indisoluble entre el modelo y la

implementación.

Y bueno, la polémica afirmación de que los

programadores tienen que ser modeladores y viceversa.

Es un punto de inflexión en cómo organizamos

los equipos de tecnología en las empresas, porque

desafía frontalmente una trampa mortal en la que

ha caído nuestra industria durante muchos años.

¿Cuál es?

El modelo de la cadena de montaje.

Ah, sí.

Durante décadas se ha promovido esta idea organizativa

de que debemos tener a unos arquitectos de

software de élite super brillantes que diseñan los

modelos conceptuales ahí arriba en su torre de

marfil.

Intocables.

Eso es.

Y luego, una vez que han terminado los

planos, se los pasan a unos programadores rasos

que, bueno, simplemente ensamblan el código como si

fueran operarios apretando tuercas en una fábrica de

coches.

Pero espera, espera.

Esto va un poco en contra de todo

lo que acompaña a la industrialización, ¿no?

A ver.

La intuición más básica nos grita que la

especialización extrema es lo que trae la eficiencia.

O sea, Henry Ford revolucionó el mundo así.

No es un desperdicio absoluto de presupuesto y

de talento que un arquitecto de sistemas de

altísimo nivel que cobra un dineral se ponga

a escribir código mundano del día a día.

Pues la intuición nos dice eso, efectivamente.

Pero aplicarlo al software es una falacia enorme,

enorme.

¿Por qué?

En la construcción tradicional o en la fábrica

de coches, el plano no es el producto,

pero en el desarrollo de software todo es

diseño.

El código fuente no es el ensamblaje, es

el diseño final en sí mismo.

Qué interesante verlo así.

Los documentos exponen un caso que es tristemente

habitual, donde un equipo tenía esta separación jerárquica

estricta.

Los modeladores estrella hicieron un trabajo excelente, pero

claro, en sus cabezas.

En la teoría.

Pasaron meses diseñando unos diagramas UML inmensos, preciosos,

que parecían obras de arte de la lógica

de negocio.

Pero en el momento en que un programador

de esa cadena de montaje intentó convertir esos

dibujos en código real, se estrelló.

Se estrelló violentamente contra las limitaciones de la

base de datos y de la red.

Como los arquitectos no bajaban a la trinchera

a tocar el código, pues nunca recibieron el

feedback empílico de esas limitaciones tecnológicas.

El papel lo aguanta todo, pero el ordenador

no.

Exacto.

El modelo colapsó y el proyecto fracasó estrepitosamente.

La conclusión del diseño guiado por el dominio

aquí es innegociable.

Todo el que modela debe tocar código y

todo el que programa debe entender y participar

activamente en la evolución del modelo.

Tienen que ser modeladores prácticos.

Hands on modelers.

Eso es.

Tienen que mancharse las manos de barro, básicamente.

Pero claro, para que un desarrollador pueda expresar

un modelo de negocio de forma tan limpia

en el código, sin volverse loco intentando que

funcione en una pantalla, la propia arquitectura técnica

del sistema tiene que ponérselo fácil.

Totalmente.

Tiene que haber como un muro de contención,

¿no?

Y ese muro de contención es lo que

conocemos como arquitectura en capas.

La famosa layered architecture.

Vale.

Si quieres que tu código hable ese lenguaje

ubicuo, tienes que aislar físicamente el dominio.

¿Aislarlo?

Sí.

Que es la capa donde viven única y

exclusivamente las reglas de negocio.

Tienes que separarlo de todas las demás preocupaciones

tecnológicas.

Separarlo de la interfaz de usuario, de la

base de datos, del envío de correos electrónicos,

de la red.

Todo.

Claro, porque si mezclas...

Es que si el código que calcula si

un cliente tiene derecho a un descuento está

mezclado en el mismo archivo con las consultas

SQL a la base de datos o con

el código que pinta un botón rojo en

el navegador, es literalmente imposible que ese código

refleje nítidamente el modelo de negocio.

Esto es fundamental para entender por qué los

sistemas se vuelven incomprensibles.

Pero ¿cómo se ve este aislamiento en la

práctica?

Me gustaría entender cómo se saca a la

luz una de esas reglas de negocio vitales

que suelen estar enterradas bajo toneladas de código

técnico.

Pues hay un ejemplo cristalino de los textos,

que es la política de overbooking.

Ah, la sobreventa.

Sí, la sobreventa en el sector del transporte

marítimo.

En este negocio es una regla estratégica crucial

permitir que un barco de carga acepte reservas

hasta un 10 por ciento por encima de

su capacidad física máxima.

Porque siempre hay cancelaciones.

Porque saben estadísticamente que siempre hay cancelaciones de

última hora.

Exacto.

Bueno, pues en el sistema heredado antiguo, esta

regla de negocio vital para la rentabilidad de

la empresa estaba oculta.

¿Dónde?

Estaba oculta como un simple y triste cálculo

matemático, un capacidad por 1 .1, embutido en

medio de un gigantesco método que guardaba datos

en la base.

Imagina ser un experto en logística marítima que

intenta auditar ese código.

Llegas, ves un asterisco, ves un 1 .1

y piensas, pero ¿qué demonios es esto?

Un misterio.

Es un impuesto portuario, una tasa de conversión

de moneda.

Esa línea no significa absolutamente nada para el

negocio.

Y si alguien, no sé, cambia ese 1

.1 por un 1 .2 por error, la

empresa puede perder millones sin que nadie se

dé cuenta.

Exacto.

Es un peligro constante.

Y al aplicar los principios de esta filosofía,

lo que hicieron los desarrolladores fue extraer ese

oscuro cálculo matemático y crearon un objeto explícito

y con nombre propio en la capa de

dominio.

¿Y cómo lo llamaron?

Lo bautizaron literalmente como política de overbooking.

Qué claridad.

De repente, esa regla de negocio tiene su

propio espacio físico en el código.

Es visible para todos.

Se puede probar matemáticamente de forma aislada.

Sin tener que levantar toda la base de

datos.

Claro, mucho más rápido.

Y lo más importante, es comprensible y auditable.

El conocimiento implícito del negocio se transformó por

fin en un artefacto de software explícito.

Vale, entiendo el proceso perfectamente.

Ya hemos aislado nuestro modelo en una capa

pura.

Todos hablamos el lenguaje ubicuo y no hay

ni rastro de esa jerga técnica mezclada con

nuestras reglas de logística o de finanzas.

Eso es.

Pero a ver, bajando un peldaño más hacia

la sala de máquinas, ¿qué forma toman las

piezas de código puro?

Porque no todo en la vida real se

comporte igual.

No todo puede ser simplemente un objeto genérico

sin más definición, ¿verdad?

No, no.

Tiene que haber matices para representar la realidad.

Totalmente.

El enfoque nos proporciona unas herramientas de categorización

muy precisas para esto.

Desglosa los conceptos del mundo real en tres

bloques de construcción principales dentro del dominio.

A ver, ¿cuáles son?

Son las entidades, los objetos de valor y

los servicios.

Vale.

Empecemos definiendo las entidades.

O entities son aquellas cosas fundamentales del negocio

que tienen un hilo de identidad constante a

través del tiempo.

Una identidad.

Sí, sin importar en absoluto si sus atributos

internos cambian.

Por ejemplo, un cliente humano.

Un cliente puede cambiar de número de teléfono

móvil, puede mudarse de ciudad o incluso cambiar

su nombre legal, pero para el sistema sigue

siendo exactamente el mismo individuo único.

Se le rastrea por un ID.

Eso es rastreado mediante un número de identificación

inmutable.

Vale.

La entidad tiene una historia de vida.

Pero a ver, ¿qué pasa con aquellas cosas

que no tienen un ciclo de vida que

nos interese rastrear?

Si yo registro, por ejemplo, una dirección de

envío en ese perfil del cliente, a mí

no me importa la historia de la calle

ni que otros clientes viven allí.

Solo me importan los datos de esa dirección

en este momento concreto.

Exacto.

¿Cómo modelamos eso sin sobrecargar la memoria del

sistema con identidades inútiles?

Pues precisamente ahí es donde entran los objetos

de valor o value objects.

Son elementos que usamos puramente para describir las

características de algo, pero que carecen de una

identidad propia que debamos o queramos rastrear a

través del tiempo.

Solo atributos.

Simplemente nos importa la combinación de sus atributos,

sí.

Entonces, a ver, para asentar bien este concepto

que me parece crucial.

Si lo entiendo bien, una entidad es como

un billete de avión a mi nombre.

Me gusta.

Si de repente la aerolínea cambia la fecha

del vuelo o me reasignan la puerta de

embarque o incluso me cambian de asiento.

Sigo siendo yo el pasajero.

Ese billete en particular tiene mi identidad atada

a él y tiene un ciclo de vida

que la aerolínea debe seguir con lupa.

Sí, sí.

Pero un objeto de valor es como, no

sé, un billete de diez euros que llevo

en el bolsillo.

Me da absolutamente igual qué billete físico sea.

Totalmente.

No me importa ni su número de serie

ni en qué carteras ha estado antes.

Solo me importa su valor intrínseco.

Si yo te doy un billete de diez

euros para pagar algo y tú, por algún

motivo, me devuelves otro billete de diez euros,

totalmente distinto, estamos en paz.

Son 100 % intercambiables.

Esa analogía es perfecta.

Fíjate.

Y fíjate en el desastre que ocurre si

nos equivocamos con esa distinción del billete a

nivel técnico.

¿Qué pasaría?

Pues que no es solo un debate filosófico

para entretenernos.

Tiene unas consecuencias enormes en el rendimiento del

código.

Si tú obligas a tu sistema de software

a tratar a todos los billetes de diez

euros como entidades, estarías forzando a la base

de datos para generar un identificador único para

cada billete.

Uf, qué locura.

Rastreando su historia individual, sus cambios de estado

y su ciclo de vida por todos los

módulos del programa.

El servidor explota.

Es un desperdicio colosal de recursos de computación

y convierte el sistema en una maraña hipercompleja.

Tratarlo como un objeto de valor que se

puede crear y destruir a voluntad sin dejar

rastro, simplifica enormemente la arquitectura.

Mucho más ligero.

Muchísimo.

Y luego tenemos el tercer bloque, que son

los servicios.

A ver, estos representan acciones, procesos o transformaciones

que no tienen un estado propio que guardar

y que no encajan de forma natural, ni

en la definición de una entidad, ni en

la de un objeto de valor.

Piensa, por ejemplo, en una operación de transferencia

de fondos entre dos cuentas bancarias.

Forzar a la cuenta A a tener un

método que se llame, no sé, transferirse a

sí misma a la cuenta B resulta forzado

y poco natural para un banquero.

No hablan así, ¿no?

La transferencia es un proceso del dominio con

entidad propia, con sus propias reglas de seguridad

y de auditoría.

Así que se modela como un servicio explícito.

Entendido.

Y finalmente, bueno, para evitar que miles de

estas entidades, valores y servicios se conviertan en

un caos visual cuando el sistema crece a

escala empresarial, utilizamos los módulos.

Para ordenar.

Piensa en los módulos como los grandes capítulos

temáticos del libro.

Que cuentan la historia de tu sistema.

Agrupan conceptos que son altamente cohesivos entre sí,

separando de forma hermética el módulo de facturación

del módulo de envíos internacionales, por ejemplo.

Muy clarificador, la verdad.

Tenemos las piezas en el tablero.

Entidades, valores, servicios y módulos.

Eso es.

Pero claro, estas piezas no viven congeladas en

el tiempo.

Como decíamos con el billete de avión, estas

estructuras nacen, sufren cambios súper complejos por parte

de los usuarios.

Y bueno, eventualmente son archivadas o borradas.

Tienen un ciclo.

Gestionar cómo nacen y cómo se recuperan los

datos sin que la lógica de negocio se

llene de ese tódigo basura de bases de

datos, pues es un reto monumental, ¿no?

Lo es.

Y para gestionar ese ciclo de vida sin

corromper el modelo puro, el diseño introduce tres

patrones muy concretos.

Los arregados, las fábricas y los repositorios.

Vamos uno a uno.

Vale.

Un agregado o aggregate es la solución para

mantener la coherencia de los datos.

Piensa en un agregado como el bloque de

un motor de combustión.

Vale.

Tú no permites que un mecánico aficionado intente

ajustar el tiempo de los pistones internos empujándolos

directamente con la mano desde fuera, ¿verdad?

No, claro.

Romperías el motor.

Exacto.

Interactúas con el motor a través de una

interfaz controlada, pues el agregado agrupa múltiples objetos,

como por ejemplo un pedido y sus líneas

de pedido, y asegura que nadie modifique las

partes internas saltándose las reglas globales.

Las invariantes, que llaman.

Eso es.

Mantener las invariantes.

Por ejemplo, garantizando que el total del pedido

siempre coincida matemáticamente con la suma de sus

líneas.

Tiene sentido.

Y para ensamblar este motor complejo desde cero,

sin que el resto del programa tenga que

conocer los detalles sucios de fabricación, utilizamos el

patrón de fábricas, las factories.

Vale.

Y finalmente, el puente hacia el almacenamiento a

largo plazo son los repositorios.

Un momento, un momento.

Vamos a ser un poco escépticos aquí con

lo de los repositorios.

A ver.

Un repositorio no es simplemente una forma elegante,

abstracta y, francamente, un poco pedante de llamar

a una consulta SQL de toda la vida

a la base de datos.

Ya, latífica duda.

Es decir, haz un select y tráeme los

datos de la tabla clientes.

¿Por qué disfrazarlo con un nombre nuevo?

A ver, entiendo la provocación.

Pero para entender por qué no es una

simple consulta con un sombrero elegante, hay que

mirar el daño psicológico del cliente.

Fíjate, el daño psicológico que hace el SQL

directo en el código de negocio.

¿Psicológico?

Sí, sí.

Si tú haces una consulta SQL tradicional o

usas herramientas básicas de bases de datos, el

sistema te devuelve datos crudos, desmembrados.

Cierto.

Te devuelve filas, te devuelve columnas y tipos

primitivos.

Psicológicamente, eso empuja al desarrollador a dejar de

pensar en reglas de negocio y empezar a

pensar en cómo cruzar tablas relacionales.

Ah, claro.

Te cambia el marco mental.

Exactamente.

Exactamente.

Un repositorio, en cambio, te devuelve un objeto

del dominio rico, un agregado completamente formado y

listo para funcionar, con todos sus comportamientos matemáticos

intactos.

Ya montado.

El repositorio actúa como un ilusionista que oculta

por completo la infraestructura técnica.

Qué buena imagen.

El desarrollador que usa el repositorio de clientes

no sabe ni le debería importar en absoluto

si por debajo hay una base de datos

Oracle carísima, un simple archivo de texto o

un microservicio en la nube.

Él sigue pensando exclusivamente en términos del lenguaje

ubicuo.

O sea, la base de datos debe servir

a tus reglas de negocio, no al revés.

Eso es.

Si dejas que la base de datos dicte

cómo se escriben tus reglas, pues terminas con

un sistema súper rígido.

Y supongo que esto es lo que permite

alcanzar ese codiciado estado que el texto llama

diseño flexible, el Supple Design, ¿no?

Exacto.

Porque si aíslas todo lo técnico, culminas en

un código con interfaces que, bueno, revelan la

intención.

Al leer el código, estás leyendo exactamente qué

está haciendo la política del negocio, mientras el

cómo técnico está cuidadosamente escondido.

Cuando alcanzas ese nivel, es que un desarrollador

recién incorporado puede leer el código de la

capa de dominio casi como si estuviera leyendo

el manual de operaciones de la empresa.

Sin ruido.

Sin tropezar con detalles sobre conexiones a bases

de datos o bucles de red.

Todo fluye.

Pero claro.

Tenemos que aterrizar esto en la cruda realidad

económica de las empresas.

Aplicar absolutamente todas estas tácticas, este nivel de

pureza arquitectónica, pulir el lenguaje ubicuo con reuniones

interminables, destilar entidades, crear repositorios perfectos.

Es mucho trabajo.

Intentar aplicar esto a un sistema corporativo gigante

de arriba abajo es literalmente suicida.

Hay demasiadas piezas, demasiadas pantallas, procesos intrascendentes.

Si un equipo intenta modelar todo el universo

de la empresa con esta profundidad se hundirán

en tiempo y quemarán todo el presupuesto en

el primer año fijo.

Seguro.

Entiendo que aquí es donde entra la necesidad

de una estrategia un poco más despiadada, ¿no?

Y aquí entramos en el verdadero corazón estratégico

de esta filosofía.

Un concepto que Evans llama la destilación.

A ver.

El éxito rotundo o el fracaso estrepitoso de

un proyecto de software a gran escala depende

casi enteramente de la capacidad del equipo directivo

y técnico para identificar el core domain, el

principal.

¿Y qué es exactamente?

Esta es esa parte minúscula, pero altamente compleja

del software que realmente diferencia a la empresa

de sus competidores.

Es, digamos, la joya de la corona que

aporta un valor estratégico único.

Lo que da dinero.

Exacto.

Todo lo demás que compone el inmenso sistema

informático corporativo son subdominios genéricos.

Ah, vale.

Cosas como un organigrama de empleados, un sistema

de autenticación de usuarios mediante contraseñas, o no

sé, un módulo de contabilidad estándar.

Son infraestructuras que son absolutamente necesarias para que

la empresa funcione.

Sí, pero no son el núcleo de tu

modelo de negocio.

No te hacen ganar contra tu competencia.

Entonces, si lo aplicamos al mundo real.

A ver, si estamos construyendo el sistema central

para un gran hospital pionero, pues el core

domain serían sin duda esos algoritmos ultra complejos

de triaje predictivo de urgencias que salvan vidas.

Eso es el núcleo, sí.

En cambio, el módulo para gestionar, no sé,

las nóminas del personal de limpieza o del

servicio de cafetería sería un subdominio genérico.

Exactamente.

Lo ideal sería comprar un software de nóminas

ya hecho, o en el peor de los

casos, pues no poner a los tres mejores

y más caros arquitectos de software del hospital

a programar un gestor de nóminas desde cero,

¿verdad?

El ejemplo es perfecto.

Pero la realidad empírica en la industria del

software, y esto es algo sobre lo que

los médicos y los textos nos advierten de

forma muy severa y reiterada, es que debido

a dinámicas humanas un poco tóxicas, a menudo

ocurre exactamente lo contrario.

No me digas.

Sí, sí.

Los mejores desarrolladores de un equipo, los veteranos

que cobran más, muchas veces huyen del barro

del negocio y se van a jugar con

tecnologías de infraestructura.

Por ego.

Por puro ego técnico, sí, o para engordar

su currículum.

Les apasiona construir frameworks abstractos o trastear con

el último sistema de mensajería distribuida y dejan

la responsabilidad de programar el modelo crítico de

negocio en manos de los programadores junior que

acaban de llegar a la empresa.

A los que no se atreven a rechistar,

claro.

Exacto, a los novatos.

Pero es una negligencia tremenda si lo piensas.

O sea, es como poner al arquitecto estrella

que ha ganado premios internacionales a diseñar el

grosor de las tuberías de los baños.

Tal cual.

Y dejar que el becario recién graduado calcule

los cimientos y la estructura de carga del

rascacielos.

Es una tragedia silenciosa que, de verdad, destruye

empresas enteras.

El libro relata con mucha frustración un caso

real donde un desarrollador senior absolutamente brillante dedicó

varios meses de trabajo a construir un sistema

periférico para gestionar comentarios de usuarios.

Comentarios, madre mía.

Sí, es un trabajo precioso.

Una arquitectura súper flexible, genérica y técnicamente deslumbrante.

Pero.

Pero mientras él se divertía con eso, un

programador muy inexperto estaba a cargo del módulo

central de evaluación de préstamos de la entidad

financiera.

Ostras.

Que era el verdadero y único motor de

ingresos del negocio.

Claro, lo importante de verdad.

Pues ese programador inexperto convirtió la lógica de

préstamos en un enredo incomprensible, súper rígido y

lleno de errores.

La elección de la destilación aquí es brutal.

Todo el esfuerzo genial y los mejores cerebros

de la empresa deben ir dirigidos, sin contemplaciones

ni excusas, al core domain.

Ahí es donde te la juegas.

Ahí es donde te juegas.

Más la supervivencia y el éxito.

Pues es una bofetada de realidad tremenda para

la industria.

Y creo que este último punto nos ofrece

la plataforma perfecta para una reflexión final brillante,

sobre todo nuestro análisis a fondo de hoy.

Lo que verdaderamente nos demuestra la filosofía del

diseño guiado por el dominio es que la

ingeniería de software, cuando se practica en su

nivel más alto y profesional, pues no trata

realmente sobre ordenadores.

Para nada.

No va a describir ceros y unos más

rápido, ni de usar el lenguaje de programación

más novedoso.

Trata sobre enfrentarse y comprender profundamente la asombrosa

complejidad y, bueno, el desorden del conocimiento del

mundo real.

Del caos humano, sí.

Ya estemos hablando de sistemas inabarcables, de envíos

globales, de modelos de derivados financieros súper complejos

o del diseño físico de hardware electrónico, pues

el verdadero y más noble trabajo de un

creador de software es empaparse de ese caos

humano y destilarlo.

En ideas puras, comunicables, claras y útiles.

Es que es un cambio de paradigma total

para cualquier profesional de la tecnología.

El código fuente es solamente el medio de

expresión.

Digamos, es la tinta en el papel.

El fin último y genuino es la captura

y el modelado del conocimiento humano para, pues

eso, para resolver problemas reales.

Así que a quienes nos escuchan hoy, tanto

si sois desarrolladores como analistas o directores de

tecnología, os invitamos a hacer un pequeño pero

revelador ejercicio mañana cuando lleguéis al trabajo.

A ver si se atreven.

Sí.

Mirad el software que sostiene vuestras empresas.

Abrid una parte crítica del código fuente o

hablad diez minutos con el equipo de desarrollo

y hacéos en silencio esta simple y poderosa

pregunta.

¿Habla de verdad este código el rico idioma

de nuestro negocio y de nuestros expertos o

sólo está balbuceando el frío y genérico idioma

de las máquinas?

La honestidad de esa respuesta os dirá muchísimo

sobre el futuro a largo plazo de ese

proyecto.

Antes de despedirnos hasta el próximo programa, os

informamos de que las voces que oyeis han

sido generadas por la IA de Notebook LM

y que dirigiendo el podcast se encuentra Julio

Pablo Vázquez, un humano que te envía saludos.

En caso de error, probablemente sean errores humanos.

Nos escuchamos.

Y hasta aquí el episodio de hoy.

Muchas gracias por tu atención.

Esto es BIMPRAXIS.

Nos escuchamos en el próximo episodio.