En la primera parte conté de dónde salió DCI: Trygve Reenskaug, el autor de MVC, pasó su jubilación buscando una forma de que el código muestre lo que el sistema hace y no sólo lo que el sistema es. La propuesta se llama Data, Context, Interaction y se resume en tres elementos. Data: los objetos de dominio quedan pequeños y apenas inteligentes — la Account sabe su saldo y sabe sumarlo y restarlo, nada más. Context: el caso de uso deja de ser un método suelto y pasa a ser un objeto de primera clase, que existe mientras el caso de uso ocurre. Interaction: los roles —SourceAccount, DestinationAccount— son comportamiento que se le pega a un objeto de datos mientras dura el contexto, y el algoritmo que ejecutan entre todos está escrito en un solo lugar, de principio a fin¹.

Me pasa cada vez que abro un sistema orientado a objetos que no escribí yo. Miro las clases, entiendo perfectamente qué es cada una —Account, Customer, LedgerEntry, Branch—, y no tengo la menor idea de qué hace el sistema. El dominio está modelado con prolijidad de manual. El caso de uso, el que el usuario tenía en la cabeza cuando pidió el software, no está en ninguna parte. Está repartido en pedacitos de dos líneas dentro de once métodos de siete clases, y para reconstruirlo tengo que hacer el trabajo del compilador a mano.

⚠️ Curiosidad nerd lateral — esto no es ciencia de la computación. Es un fierro con luces.

Hay una forma de que una computadora te mire de vuelta, y es el panel de control. No la pantalla: el panel. La fila de lámparas que parpadea con el contenido de un registro, la llave que detiene el procesador a mitad de una instrucción, el disco hexadecimal donde marcás la dirección del dispositivo desde el que querés arrancar. La imagen que encabeza este post es exactamente eso: la consola de un IBM System/370 Modelo 145, la máquina de la que trata todo lo que sigue.¹