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.
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.