El software debe crecer sin volverse incomprensible.
EOSX persigue una idea a largo plazo: la complejidad no debería gestionarse principalmente mediante cada vez más código interdependiente. La ingeniería debe funcionar mediante capacidades, relaciones, composición y evolución controlada.
Capacidades como punto de partida
La pregunta central cambia de «¿Qué código escribimos?» a «¿Qué capacidades necesita el sistema y cómo deben colaborar?»
Evolucionar lo existente
EOSX no solo debe permitir sistemas nuevos. Las soluciones existentes deben poder analizarse, importarse y modernizarse progresivamente.
Del software a la técnica
La misma idea puede transferirse a dominios muy diferentes si sus capacidades, reglas y relaciones pueden describirse claramente e implementarse correctamente.
Desarrollo activo
La arquitectura continúa desarrollándose y validándose en diferentes escenarios. Los detalles técnicos internos no se publican completamente.
Composición en lugar de crecimiento de código
Los nuevos requisitos deben representarse mediante capacidades y relaciones siempre que sea posible, evitando aumentar continuamente la complejidad monolítica.