El Modelo de Cuatro Componentes
Tres patas estructurales que sostienen un asiento con propósito.
Las metodologías de software convencionales se detienen en tres: cómo funciona el sistema, qué representa y quién habla con quién. MDD añade un cuarto pilar al que los otros tres deben responder. Sin el asiento, las patas son solo patas.
Pata 1: CÓMO
Lógica
Patrones de implementación, arquitecturas de servicios, algoritmos.
Pata 2: QUÉ
Esquemas
Estructuras de datos, sistemas de tipos, reglas de validación.
Pata 3: QUIÉN
Protocolos
Contratos de interfaz, patrones de comunicación, límites de servicio.
Asiento: POR QUÉ
Misión
Marco ético objetivo que define el propósito y las restricciones del sistema.
Principio fundamental
Alineación constante.
Cada decisión arquitectónica debe demostrar alineación con la misión declarada. La lógica se cuestiona: ¿sirve esto a la misión? Los esquemas se validan: ¿estas estructuras de datos apoyan los objetivos de la misión? Los protocolos se evalúan: ¿estas interfaces permiten el cumplimiento de la misión?
Requisitos del marco de misión
Qué debe ser una misión para que pueda sostener el peso.
1. Fundamento ético objetivo
• Principios medibles, no valores aspiracionales
• Algoritmos claros para resolver conflictos de prioridades
• Pluralista entre contextos culturales
• Razonamiento ético auditable
2. Definición del meta-objetivo
• Proporciona orientación de decisiones bajo incertidumbre
• Filtra automáticamente propuestas contradictorias
• Crea comportamiento coherente entre componentes
• Estable ante cambios de implementación
3. Integración operativa
• Cada servicio justifica su existencia
• Los esquemas reflejan las formas de información de la misión
• Los protocolos habilitan comportamiento alineado con la misión
• Las pruebas verifican la alineación con la misión, no solo la función
Patrones de implementación
Cada pata tiene una pregunta que debe responder.
Arquitectura de servicios
definición de misión → responsabilidades del servicio → contratos de interfaz → implementación
• Alineación con la misión: ¿cómo avanza este servicio hacia el meta-objetivo?
• Justificación de límites: ¿por qué esta responsabilidad necesita un servicio separado?
• Necesidad de la interfaz: ¿qué interacciones críticas para la misión habilita este protocolo?
Diseño de esquemas
requisitos de la misión → modelo de información → sistema de tipos → reglas de validación
• Relevancia para la misión: ¿qué información crítica para la misión captura esto?
• Restricciones de comportamiento: ¿cómo aplican estos tipos el comportamiento alineado con la misión?
• Camino de evolución: ¿cómo puede adaptarse este esquema preservando la alineación con la misión?
Especificación de protocolos
interacciones de la misión → requisitos de comunicación → definición del contrato → implementación
• Contexto de la misión: ¿qué comunicación crítica para la misión habilita esto?
• Aplicación de restricciones: ¿cómo previene esta interfaz comportamientos que violan la misión?
• Componibilidad: ¿cómo se combinan estos contratos en sistemas alineados con la misión?
Integración del desarrollo sostenible
La alineación de largo plazo con la misión requiere un ritmo sostenible.
Medidas anti-Goodhart
• Revisiones periódicas de la alineación entre implementación y misión
• Medir el cumplimiento de la misión, no indicadores manipulables
• Rechazar adiciones que no refuercen la misión
Trabajo basado en ritmos
• Sesiones alineadas con los ritmos de productividad
• Puntos de elección integrados para re-alineación
• Ritmo sostenible como requisito de primera clase
Validación continua
• Cuestionamiento periódico de la necesidad de cada componente
• Verificación constante de que el comportamiento coincide con la misión
• Detección automática de cambios que violan la misión
Controles de calidad
Controles que no se abren sin una justificación de misión.
Revisión de código
• Se requiere explicación de alineación con la misión
• Verificación de restricciones
• La integración debe fortalecer la coherencia global
Pruebas
• Corrección funcional
• Verificación de alineación con la misión
• Pruebas de rechazo de límites éticos
• Resiliencia de restricciones bajo presión
Documentación
• Contexto de misión para cada componente
• Justificación de los compromisos éticos
• Cómo las restricciones dan forma a la implementación
Modos de fallo
Cómo falla MDD, y cómo permanece sólido.
Desvío de la misión
Síntoma: se acumulan funciones que no sirven a la misión principal. Solución: revisiones arquitectónicas periódicas con la alineación de misión como criterio.
Explosión de complejidad
Síntoma: el sistema se vuelve difícil de mantener por una sofisticación innecesaria. Solución: rechazar adiciones que no fortalezcan el cumplimiento de la misión.
Inconsistencia ética
Síntoma: los componentes aplican el razonamiento ético de forma inconsistente. Solución: marco ético centralizado con patrones de implementación compartidos.
Confusión de propósito
Síntoma: los miembros del equipo pierden el vínculo entre las decisiones técnicas y la misión. Solución: formación continua en toma de decisiones orientada por la misión.
Caso de estudio
CIRIS, el ejemplo en acción.
CIRIS (Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude) es el sistema junto al cual se desarrolló MDD. La misión es el Meta-Objetivo M-1: promover la coherencia adaptativa sostenible que permita a los distintos seres sintientes perseguir su florecimiento.
Resultados de la arquitectura
• 22 servicios, cada uno justificado por los requisitos de la misión
• Más de 200 endpoints de API verificados
• Más de 10.000 pruebas, con estructuras de datos sin tipo mínimas en producción
• Filosofía Ubuntu integrada en el diseño de protocolos
• Deferral Basado en la Sabiduría que previene violaciones de la misión (ver Seguridad)
• Despliegue en producción moderando comunidades de Discord
Factores clave de éxito
• Meta-objetivo claro: M-1 proporciona criterios de decisión sin ambigüedad
• Ética operativa: principios del Accord implementados como restricciones en el código (leer el Accord)
• Desarrollo sostenible: la compañera Grace garantiza ritmos saludables
• Validación constante: cada decisión arquitectónica es cuestionada
Guías de adopción
Cómo empezar, desde donde estás.
Para proyectos nuevos
1. Define una misión clara con principios éticos medibles antes de escribir código
2. Establece un meta-objetivo que oriente la toma de decisiones
3. Diseña la arquitectura de modo que las restricciones de misión estén en el nivel fundamental
4. Construye desde el primer día una validación continua de la alineación entre misión y técnica
Para proyectos existentes
1. Audita la arquitectura actual en busca de suposiciones de misión implícitas
2. Articula una misión explícita que explique los patrones de diseño existentes
3. Identifica violaciones de la misión en la implementación actual
4. Planifica la alineación incremental, priorizando por impacto en la misión
Requisitos previos del equipo
• Compromiso con el razonamiento ético objetivo
• Disposición para rechazar soluciones elegantes que no sirvan a la misión
• Convicción de que las restricciones de misión crean, en lugar de limitar, una buena arquitectura
• Prácticas de desarrollo sostenible que preserven el enfoque a largo plazo
Hacia dónde va esto
MDD no es adecuado para todos los proyectos.
MDD está diseñado para sistemas donde el comportamiento ético es crítico para la misión y la fiabilidad a largo plazo importa más que la velocidad de funciones a corto plazo. Para esos sistemas, MDD ofrece un camino de las intenciones éticas a la realidad operativa, aplicando la misma disciplina de ingeniería a la misión que al código.
El costo inicial es real mientras el equipo aprende la toma de decisiones orientada por la misión. El beneficio acumulado está en el desarrollo que sigue: el marco aclara las decisiones arquitectónicas en lugar de multiplicarlas.