DCI: la idea olvidada del hombre que inventó MVC

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.

Resulta que el tipo que inventó MVC pensaba lo mismo, y propuso una solución. Se llama DCI —Data, Context, Interaction— y casi nadie la conoce. Este post cuenta de dónde salió y qué dice. En la segunda parte lo escribimos en Python, y analizamos la conveniencia y limitaciones del lenguaje.

El currículum obliga a escuchar

Trygve Reenskaug —suerte para mí que no me toca pronunciarlo— fue el autor del patrón Model-View-Controller. Los dos documentos fundacionales siguen publicados en su propia página: «Thing-Model-View-Editor», del 12 de mayo de 1979, y «Models-Views-Controllers», del 10 de diciembre de 1979. El primer nombre que le puso fue Thing-Model-View-Editor; el que quedó salió recién después de discutirlo largo con Adele Goldberg¹. Eso solo ya es raro de asimilar: MVC es probablemente la sigla más repetida de la historia del software de aplicación, la que aparece en el primer capítulo de todo tutorial de framework web desde hace veinte años, y tiene un autor con nombre, apellido y página personal todavía en línea en un servidor universitario noruego². Reenskaug fue profesor emérito de informática en la Universidad de Oslo —así firmaba él mismo sus papers de DCI³— y se había retirado en 1997, lo que hace que todo lo que sigue sea, literalmente, su proyecto de jubilación⁴. Lamentablemente falleció en 2024, a los 93 años.

Pero MVC ni siquiera es el principio de la historia; empezaremos por el principio porque explica todo lo demás.

En los años sesenta Reenskaug trabajaba en Autokon⁵, un sistema CAD/CAM para diseño de barcos que entró en producción en 1963 y que terminaron usando la mayoría de los astilleros importantes del mundo⁶. Y ahí pasó algo que él contaba, cuarenta años después, como el origen de todo. El sistema guardaba el modelo del producto en una base de datos central⁷. Alguien despierto en el departamento de trazado se dio cuenta de que, si el modelo ya estaba en la base, se podían sacar directamente de ahí las cintas de control para las máquinas de oxicorte. Cortaron más de trescientas toneladas de acero antes de descubrir la diferencia entre precisión y exactitud: los datos tenían cuarenta bits de precisión, sí, pero las dimensiones seguían siendo tan aproximadas como en los planos 1:50 de los que habían salido⁸.

Trescientas toneladas de chatarra y muchos dedos acusadores. Reenskaug concluyó que la culpa era del sistema, no del muchacho: antes, cada departamento era dueño de sus datos, y la transferencia entre departamentos estaba controlada, firmada por quien la mandaba y chequeada por quien la recibía. La base de datos común había roto ese patrón. No había dueño y no había control.

De ahí salió su obsesión: los sistemas de computación tienen que reflejar la estructura de responsabilidad de la organización real. Intentó construirlo con Simula —que Nygaard y Dahl acababan de inventar en el Norsk Regnesentral⁹, del otro lado del patio de su oficina¹⁰— y se dio contra dos paredes. Una: un programa Simula corría segundos o minutos, y sus objetos nacían y morían dentro de esa corrida; él necesitaba que la ejecución durara un año o más. Es el problema de la persistencia¹¹, y en 1970 no tenía solución — «los objetos persistentes todavía estaban esperando ser inventados», anotó él mismo entre paréntesis¹²; el término persistent programming aparece recién en 1983, con PS-algol¹³. La otra fue el verdadero problema: Simula exigía que el emisor de un mensaje conociera la clase del receptor. Eso rompía la idea entera de componentes que se comunican por un protocolo estándar y son opacos por dentro. Chau Simula.

Sin lenguaje que le sirviera, se construyó las dos cosas a mano. En el paper que llevó a la conferencia ICCAS de Tokio, en agosto de 1973, describe el lenguaje Prokon-0 y su principio de Communicating Data Processes: los procesos viven guardados en la base de datos, pasivos la mayor parte del tiempo, y se cargan a memoria recién cuando les llega un mensaje; cuál procedimiento se ejecuta lo decide una tabla que cada proceso tiene para sí, de modo que el mismo mensaje puede ser atendido de manera diferente en procesos distintos¹⁴. Persistencia y despacho dinámico, escritos a mano en un astillero noruego.

El proyecto se cayó cuando se derrumbó el mercado de barcos nuevos, y con el tiempo libre que le quedó escribió los papers que después lo llevaron a Xerox PARC como científico visitante en 1978/79, al grupo de Smalltalk. Ahí las ideas encajaron. En el grupo, contaba él, decían que había dos escuelas de orientación a objetos: la de la Costa Este, la de C++, «un artefacto de programación donde un objeto es una instancia de una clase y también una estructura de datos con métodos incorporados»; y la de la Costa Oeste, la de ellos, donde «la esencia de la orientación a objetos es que los objetos interactúan para realizar una tarea»¹⁵. Toda la historia posterior de DCI es un intento de escribir código de acuerdo con esa segunda definición.

Si bien coincidía con la definición de orientación a objetos de Alan Kay, sus reparos apuntaban a dos supuestos de la implementación de Smalltalk. El primero: que si un objeto está programado «para hacer lo correcto», se va a portar bien cuando interactúe con otros. Anda en los casos simples y falla en los sistemas donde el valor del todo es mayor que la suma de las partes, porque ahí qué es «lo correcto» depende del sistema entero — es decir, del contexto. El segundo: que la clase sea la unidad ideal de reutilización. Las clases se diseñan de a conjuntos y fuera de su conjunto no sirven; el ejemplo que da es el framework, un montón de clases que se complementan y que están pensadas para derivar subclases juntas. Su conclusión es de una línea: «las clases no son independientes, y hace falta un constructo de nivel más alto para especificar el todo»¹⁶. Treinta años después, ese constructo de nivel más alto es la C de DCI.

Le siguió el paradigma de roles y el método OOram —Object Oriented Role Analysis and Modeling—, cuya primera herramienta demostró en el primer OOPSLA, en Portland, en 1986¹⁷. Llegó a formato libro como Working with Objects: The OOram Software Engineering Method, escrito con Per Wold y Odd Arild Lehne¹⁸. Reenskaug venía pensando hace décadas que la unidad interesante no es el objeto, sino el rol que el objeto juega mientras algo pasa.

timeline TD
    title De un astillero noruego a DCI
    1963 : Autokon entra en producción
         : 300 toneladas de acero mal cortado
    1970 : Simula descartado
         : el emisor debe conocer la clase del receptor
    1973 : Prokon-0 y los Communicating Data Processes
         : ICCAS, Tokio
    1978 : Xerox PARC, grupo Smalltalk
    1979 : Thing-Model-View-Editor
         : Models-Views-Controllers (MVC)
    1986 : OOram en el primer OOPSLA (Portland)
    1997 : se jubila y arranca BabyUML
    2008 : BabyUML pasa a llamarse BabyDCI
    2009 : el paper de Artima
    2014 : capítulo ASA y Working with objects

Y después, décadas más tarde, llegó DCI. Acá conviene ser preciso con las fechas. El 28 de agosto de 2008 Reenskaug declaró que su proyecto BabyUML había llegado a su meta y lo rebautizó BabyDCI: esa «versión 2008» es la fecha de nacimiento del paradigma, y él mismo la escribía así¹⁹. El paper —The DCI Architecture: A New Vision of Object-Oriented Programming, firmado junto con James O. Coplien— se publicó en Artima recién el 20 de marzo de 2009²⁰.

Lo de «Baby», dicho sea de paso, tiene dos motivos. El primero es literal: la versión de 2008 era una criatura que él esperaba que creciera hasta convertirse en algo viable y potente. El segundo es una humorada con ambición: el primer computador electrónico digital de programa almacenado del mundo, en Manchester en 1948, se llamaba The Baby²¹. «Como todos sabemos, mucho vino después de ese comienzo endeble»²².

Que DCI haya salido del escritorio de Reenskaug y llegado a alguna parte es obra de Coplien, y no hace falta que lo diga yo: lo decía Reenskaug. «Después de 2008, DCI salió al mundo bajo el liderazgo de James Coplien. Sin él, DCI habría quedado como una curiosidad oscura»²³. Y fue Coplien quien lo llevó a formato libro: Lean Architecture for Agile Software Development lo escribió con Gertrud Bjørnvig —no con Reenskaug²⁴—, y es ahí donde la idea aparece desarrollada. El propio Reenskaug lo reseñó como «una lectura obligada para todos los que quieran entender la verdadera naturaleza del desarrollo de sistemas».

Cuando el inventor de MVC dice, cuarenta años después, «che, esto se puede hacer mejor», uno se sienta a escuchar.

El síntoma: ¿dónde está el comportamiento?

El diagnóstico de DCI es corto y es incómodo.

La orientación a objetos, tal como se practica, modela muy bien lo que las cosas son. Una Account tiene un saldo, un titular, un CBU. Eso es estable: la cuenta va a seguir siendo una cuenta el año que viene, y ese modelo casi no cambia. Hasta ahí, todo bien.

classDiagram
    direction LR
    class Customer {
        +name
        +tax_id
    }
    class Account {
        +holder
        +balance
        +debit(amount)
        +credit(amount)
    }
    class LedgerEntry {
        +date
        +amount
    }
    Customer "1" --> "*" Account : holds
    Account "1" --> "*" LedgerEntry : records

Mirá ese diagrama y decime qué hace el sistema. No se puede. Está todo lo que el sistema es y no hay una sola pista del problema que resuelve.

Porque el sistema no existe para que las cuentas sean cuentas. Existe para que alguien transfiera plata, pague un servicio, cierre un ejercicio. Eso es lo que el sistema hace, y es también la parte que cambia todo el tiempo. En OOP clásica esa parte no tiene dónde vivir. Las opciones son dos, y las dos son malas.

La primera: metés el comportamiento adentro de los objetos de dominio. Entonces Account empieza a tener un método transfer_to(), y después pay_bill(), y después apply_court_order(), y a los tres años tu clase Account tiene mil quinientas líneas y sabe de juzgados. El objeto estable se contaminó con todos los casos de uso inestables que lo tocan.

La segunda: sacás el comportamiento afuera, a una capa de servicios. Entonces Account queda anémica —un montón de getters y setters, una fila de la base de datos con disfraz de objetos— y toda la lógica vive en TransferService, que es un procedimiento con sombrero de objeto. Escribiste COBOL con llaves.

Coplien tiene un nombre prestado de la arquitectura de verdad para esto: las shear layers, las capas de una construcción que evolucionan a ritmos distintos. Una casa necesita techo nuevo cada tantos años pero casi nunca necesita una pared exterior nueva, y una buena arquitectura pone interfaces limpias entre esas capas. La programación orientada a clases, dice, mete la evolución de los datos y la evolución de los métodos en la misma capa: la clase. Los datos tienden a ser estables; los métodos cambian todo el tiempo para dar servicios nuevos. Esa diferencia de ritmos es la que le hace fuerza al diseño hasta romperlo²⁵.

DCI dice que las dos opciones de arriba son malas porque las dos parten de una pregunta equivocada. La pregunta no es «¿en qué clase pongo este método?». La pregunta es «¿por qué el caso de uso no es una cosa?».

Las tres letras

La propuesta de DCI es partir el sistema en tres, y darle a cada parte un criterio de cambio distinto²⁶.

Data es lo que el objeto es. Chiquito, tonto, estable. La Account sabe su saldo y sabe sumarlo y restarlo, y nada más. Es el modelo de datos, la parte que dura décadas. Coplien lo llama, sin cariño y con precisión, barely smart data.

Context es la novedad, y es la letra que hace toda la fuerza. El caso de uso deja de ser un método suelto y pasa a ser un objeto de primera clase. MoneyTransferContext no es un servicio: es un contexto, una cosa que existe, que se instancia cuando la transferencia empieza y que muere cuando termina. Su trabajo es uno solo: agarrar los objetos de datos que participan y asignarles los roles que van a jugar en este caso de uso puntual.

Interaction es el guion. Los roles —SourceAccount, DestinationAccount— no son clases, no son objetos: son comportamiento que se le pega a un objeto de datos mientras dura el contexto. Y la interacción es el diálogo entre roles: el origen se debita, el destino se acredita, y listo.

flowchart LR
    subgraph CTX["Context: MoneyTransferContext (vive sólo durante el caso de uso)"]
        direction TB
        R1["source<br/>rol SourceAccount<br/><i>transfer(amount)</i>"]
        R2["destination<br/>rol DestinationAccount<br/><i>receive(amount)</i>"]
        R1 == "el guion: debita y pide acreditar" ==> R2
    end
    subgraph DATA["Data: objetos de dominio (viven siempre)"]
        direction TB
        O1["account_a : Account<br/>balance = 1000"]
        O2["account_b : Account<br/>balance = 0"]
    end
    R1 -. "se liga al entrar<br/>se suelta al salir" .-> O1
    R2 -. "se liga al entrar<br/>se suelta al salir" .-> O2
    classDef rol fill:#fde8d0,stroke:#c8792a,stroke-width:2px
    classDef dato fill:#e6eef7,stroke:#3d6b9c,stroke-width:2px
    class R1,R2 rol
    class O1,O2 dato

Los nombres de los roles no se inventan, y ese es un punto en el que Reenskaug y Coplien insistían bastante: salen del modelo mental del usuario. «Podés reconstruirlos fácilmente pidiéndole a cualquiera que tengas cerca que te describa cómo se transfiere plata entre sus cuentas, y escuchando con atención lo que dice»²⁷. Va a nombrar los objetos por el papel que juegan en la transacción. Eso es un rol.

La clave, la que hace que valga la pena todo el aparato, es esta: en el contexto vos leés el algoritmo completo del caso de uso, de corrido, en un lugar. Y se lee como el usuario lo cuenta. «Tomás fondos del origen, los ponés en el destino.» No hay que perseguirlo por siete archivos.

El ejemplo que todo el mundo usa

El ejemplo canónico de DCI es la transferencia bancaria: es el que usan Reenskaug y Coplien en el paper de Artima, con un caso de uso de cajero automático²⁸, y el que desarrollan en el capítulo de arquitectura, donde dicen que «un modelo mental posible tiene tres roles»: Source Account, Destination Account y Transfer Amount²⁹. Ese tercero es el interesante: el monto no es una entidad del dominio y sin embargo puede ser un rol. Un rol no tiene por qué corresponder a una tabla.

Es un ejemplo bien elegido porque parece trivial y no lo es.

En OOP clásica, si escribís source.transfer_to(destination, amount), la Account origen ahora sabe qué es una transferencia. Sabe de comisiones, sabe de límites diarios, sabe de horarios de acreditación. Le cargaste un caso de uso a una entidad que existía antes de que ese caso de uso se inventara y que va a seguir existiendo cuando lo deroguen. Y ninguna de esas reglas es sobre lo que una cuenta es.

En DCI, Account no sabe nada de transferencias. Sabe debitar y acreditar, punto — como un entero sabe sumarse. Ni siquiera valida que no quedes en descubierto, porque el piso del saldo no es un dato de la cuenta: en una caja de ahorro es cero, en una cuenta corriente con acuerdo de descubierto es el negativo del acuerdo, y una comisión o un embargo te dejan en rojo sin preguntar. El contexto MoneyTransferContext toma dos cuentas cualesquiera, le dice a una «vos, en este rato, sos la SourceAccount» y a la otra «vos sos la DestinationAccount», y ejecuta el guion. La misma cuenta que hoy es origen mañana es destino, y no le agregaste ni una línea.

El detalle que a mí me parece más interesante: los roles son contextuales. Un objeto no tiene un rol, un objeto juega un rol, y sólo mientras dura la obra. Cuando el contexto termina, la cuenta vuelve a ser una cuenta. Eso es mucho más parecido a cómo funciona el mundo real que la herencia, donde una vez que sos SalariedEmployee lo sos hasta que destruyan el objeto.

Además —esto importa para lo que viene— el objeto tiene que seguir siendo el mismo objeto mientras juega el rol. No alcanza con envolverlo en un decorador y devolver otra cosa: la identidad se conserva. Ahí es donde la idea empieza a necesitar del lenguaje funcionalidades que el lenguaje no posee, y de eso se trata la segunda parte.

La tesis fuerte, entonces, es esta: el código tiene que leerse como el modelo mental del usuario, no como el diagrama de clases del arquitecto. El diagrama de clases te dice qué hay. El contexto te dice qué pasa. Los usuarios no piensan en qué hay; piensan en qué pasa. Coplien lo dice más filoso: «vendemos casos de uso, no clases, y ni siquiera objetos»³⁰.

Las críticas serias

Conviene no presentar esto como una idea perfecta que el mundo ignoró por tonto. Las objeciones aparecieron rápido y algunas son buenas.

La más citada es de Michael Feathers, y va al corazón del ejemplo: poner la responsabilidad de la transferencia en la cuenta origen es arbitrario. En el modelo mental del usuario, la transferencia no la hace ninguna de las dos cuentas; la hace el banco, o un objeto-transacción. John Zabroski propuso directamente una clase de análisis TransferSlip — el papelito de la transferencia — como el lugar donde vive esa lógica³¹. Y es una crítica incómoda porque DCI se vende justamente por respetar el modelo mental del usuario. Si el ejemplo canónico no lo respeta, algo falla.

Otros dijeron que DCI no era nada nuevo: que son traits con otro nombre, o la vieja idea funcional de que los algoritmos importan y deberían poder escribirse de corrido. La respuesta de Coplien es que los traits son una forma de implementarlo y que otros constructos sirven igual; el valor está en separar el comportamiento estable del dominio de la lógica de negocio contextual, no en el mecanismo³². Reenskaug, por su lado, contestó algo más duro y menos tranquilizador: que entender DCI exige adoptar una abstracción adicional —el rol— y que el rol es la abstracción opuesta a la clase. La clase deja afuera la identidad del objeto y se concentra en su construcción interna —atributos y métodos—; el rol hace lo contrario: deja afuera la construcción interna y se concentra en la identidad. Por eso, decía, DCI le resulta tan difícil a una persona formada en clases: «tratá de explicarle la noción de color a alguien completamente daltónico; tratá de explicarle la noción de rol a alguien centrado en clases»³³.

Uno puede leer eso como profundidad o como la respuesta de alguien que ya decidió que quien no entiende es porque no puede. Yo creo que hay las dos cosas.

Y después está la evidencia, que es escasísima: hay un solo experimento controlado con sujetos humanos comparando DCI con OO clásica, la tesis de maestría de Hector A. Valdecantos en el RIT, de 2016, con versión de conferencia en ICPC 2017³⁴. El resultado es honesto y moderado: el código DCI resultó más comprensible y logró que los programadores concentraran mejor la atención en los archivos que importaban, pero el estudio no pudo mostrar con significancia estadística que se resolviera la tarea en menos tiempo. Un experimento, con estudiantes, sobre un sistema chico. Cualquiera que te diga que DCI está probado —o refutado— está hablando de más.

Por qué (casi) nadie lo usa

La respuesta tiene tres partes.

La primera es que el lenguaje pelea en contra. Para que DCI funcione de verdad necesitás poder inyectar comportamiento a un objeto en tiempo de ejecución, por la duración de un contexto, sin tocar su clase y sin que el objeto cambie de identidad. Java no hace eso. C# no hace eso. Los lenguajes con traits o mixins te dejan acercarte, pero la composición suele ser estática, decidida al definir el tipo y no al armar el contexto. Ruby y Python sí te dejan hacerlo — y el precio que se paga es exactamente el tema de la parte 2. Coplien terminó escribiendo un lenguaje entero, trygve, precisamente para no tener que pelear; y trygve es un proyecto de GitHub con cien estrellas³⁵.

La segunda es que no hay ecosistema. No hay un framework DCI con diez mil estrellas, no hay una generación de programadores que lo aprendió en la facultad, no hay ofertas de laburo que lo pidan. Y las ideas de arquitectura, guste o no, se propagan por framework y por oferta laboral, no por paper.

La tercera es la más honesta: el beneficio recién se ve cuando el sistema es grande. En un CRUD de cuatro pantallas, DCI es puro overhead: te hace escribir contextos y roles para algo que se resolvía con un método. El dolor que DCI cura es el de los sistemas de diez años y cien casos de uso, y para cuando llegás a ese dolor ya tenés cien mil líneas escritas del otro modo. El costo se paga por adelantado y el retorno llega tarde. Eso, en cualquier organización, tiene una respuesta: «no lo hagas así».

Lo que sí sobrevivió

Lo interesante de las ideas que no ganan es que casi nunca desaparecen del todo: se filtran.

El diagnóstico de DCI —que el caso de uso merece ser una cosa y no un método perdido— es exactamente el mismo diagnóstico que hace Clean Architecture cuando pone los use cases en el centro y los convierte en objetos con nombre propio³⁶. La solución es distinta y bastante menos ambiciosa: los use cases de Clean Architecture son objetos comunes, no hay inyección de roles en ningún lado, nadie le cambia la clase a nada. Pero el síntoma que describe es idéntico.

Y comparten algo más, que yo no esperaba y que desde acá no se ve. Al escribir la segunda parte —donde esto se implementa de verdad— resultó que el mecanismo canónico de DCI, el de reasignarle la clase al objeto mientras juega su rol, no funciona sobre una entidad que hereda de la clase base de un ORM. No es una cuestión de estilo: el intérprete se niega. Así que la frontera que Clean Architecture y DDD te piden por razones de diseño, DCI te la cobra en tiempo de ejecución.

Vale la pena igual

Yo no te voy a decir que uses DCI. No lo uso, no conozco a nadie que lo use, y ya expliqué por qué la economía no cierra.

Pero pensá en el arco completo. Un tipo empieza en 1963 escribiendo un sistema que corta acero para barcos. El sistema funciona tan bien que alguien lo usa para algo que no debía y se pierden trescientas toneladas de material. Él decide que la culpa es del diseño, no del que apretó el botón. Se pasa los sesenta buscando cómo hacer que los programas reflejen quién es responsable de qué. Rechaza Simula, va a PARC, inventa MVC casi de costado —tan de costado que rechazó la invitación de Byte a escribir sobre el tema porque le parecía obvio—, y sigue.

Se jubila en 1997 y, en vez de dedicarse a cultivar el jardín, se pone a trabajar en el mismo problema que lo venía molestando desde hacía treinta años. A los 78 publica el paper que lo resume. A los 83 sigue escribiendo sobre eso. Murió el 14 de junio de 2024, una semana antes de cumplir 94, sin haber visto que la idea prendiera³⁷.

Eso no es un fracaso. Es alguien que a los setenta y ocho años seguía tratando de arreglar lo que había ayudado a construir, en vez de disfrutar de los laureles conseguidos. La industria del software tiene mucha gente que a los cuarenta ya vive de una charla que dio a los treinta y cinco. Reenskaug hizo lo contrario.

Cada vez que abro una carpeta services/ llena de clases terminadas en Service, con métodos de trescientas líneas que orquestan objetos anémicos, me acuerdo de eso. No de la técnica. Del tipo.

Si querés seguir, hay una tarde entera de material y está todo libre. El paper de Artima es la puerta de entrada³⁸. The Roots of DCI son nueve páginas autobiográficas que se leen como una charla de sobremesa y explican de dónde salió todo, chatarra de astillero incluida³⁹. El libro de Coplien y Bjørnvig es el desarrollo largo⁴⁰. Y si preferís que te lo cuenten, están las charlas de Coplien en video, incluida una conversación informal de 2023 que es lo más reciente que hay del tema⁴¹.

Y si querés dejar de leer y empezar a escribir: en la segunda parte implementamos todo esto en Python, de cero y sin librerías. Lo que anda y lo que no.

Apéndice: quién es quién

• Trygve Reenskaug (1930-2024), noruego. Autokon, MVC, OOram, DCI. Profesor emérito de la Universidad de Oslo.
• James O. Coplien («Cope»), estadounidense. Comunidad de patrones, Lean Architecture, el lenguaje trygve.
• Adele Goldberg, del grupo de Smalltalk en Xerox PARC. Con ella discutió Reenskaug el nombre de MVC.
• Alan Kay, Smalltalk y el Dynabook. Reenskaug suscribía su definición de orientación a objetos; sus dos reparos, anotados en The Roots of DCI, eran a la implementación de Smalltalk, no a la definición.
• Kristen Nygaard y Ole-Johan Dahl, los autores de Simula, del otro lado del patio de la oficina de Reenskaug.
• Ivar Jacobson, los casos de uso — que en la lectura de Coplien quedaron «al lado de, pero no en el centro de» la arquitectura.
• Rebecca Wirfs-Brock, diseño dirigido por responsabilidades y las tarjetas CRC. Coplien cuenta que quiso rebautizarlas «RRC» —Roles, Responsibilities, Collaborators— y que al final dejó la sigla intacta y reemplazó Class por Candidate, «como un rol». La fuente es un correo privado de ella a Coplien, del 14 de octubre de 2009, citado en el capítulo de arquitectura⁴².
• Christopher Alexander, el arquitecto (de edificios) del que salió la idea de patrones.
• Michael Feathers, el crítico más citado de DCI.
• Gertrud Bjørnvig, coautora de Lean Architecture.

• DCI
• Reenskaug
• MVC
• Arquitectura
• OOP
• Coplien
• Smalltalk
• Simula