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.

El legendario Jim Weirich¹ presenta Decoupling from Rails en la reunión del Cincinnati Ruby Brigade de Octubre 2013. En 2011 Robert C. Martin² desafió a la comunidad de Ruby on Rails³ a desacoplar la aplicación del framework Web. Jim toma un pequeño ejemplo y lo desarrolla con la claridad y maestría que lo caracterizaba, que puedes ver en el vídeo⁴.

DHH⁵ esbozó una crítica⁶, pero es claro que se sintió tocado en su diseño de RoR. En el enlace se aprecian los comentarios y respuestas de otros miembros de la comunidad. En particular me interesó la respuesta de Pat Maddox⁷, si bien puede verse como contemporizadora.