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

Antes de escribir la primera ruta de un backend nuevo, vale la pena invertir un rato en el tooling que va a hacer cumplir la calidad del código automáticamente¹. La apuesta es simple: “está prolijo” tiene que ser lo que pasa por default, no lo que alguien se acuerda de hacer antes de un commit. Esto es lo que arma esa base en un proyecto Python real — la configuración es genérica a propósito: no hay una línea de negocio, ni un nombre de cliente, ni nada que identifique de dónde sale. El conjunto de herramientas (tooling) y sus configuraciones iniciales es lo que se puede compartir entre un proyecto y otro. Armé además un scaffold público con todo esto funcionando de verdad — cloná, make install, y andá probando cada sección de este post contra el repo real².

Todo el mundo que estudió ciencias de la computación implementó “una máquina de Turing” en algún momento¹: una cinta, un cabezal, una tabla de transiciones (estado, símbolo) → (estado, símbolo, movimiento). Es un ejercicio válido, pero no es lo que Turing escribió en 1936. Su notación real —la que usa en On Computable Numbers, with an Application to the Entscheidungsproblem²— es bastante más rica que eso, y casi nadie la implementa como está en el paper. Yo quería saber si podía.