OTAKU es un acrónimo, y cada letra es una restricción. Cuarenta reglas lo hacen medible; una métrica decide si un método es demasiado complejo para existir.
La filosofía tiene un núcleo rígido y bordes flexibles. El núcleo —los cinco pilares y los umbrales que los operacionalizan— no negocia. Los bordes —lenguaje, framework, estilo, herramientas— son libres.
Los cinco pilares tienen un orden intencional. La disciplina va primero porque nada sobrevive sin ella. Los contratos van al final porque son lo único que el mundo exterior puede ver.
Domina tu Disciplina
Sé estricto contigo mismo.
La restricción es el único camino a la libertad. Complejidad, tamaño y nombres se miden, no se debaten.
Herramientas para la Composición
Compón como Unix.
Piezas pequeñas con entradas y salidas claras. La aplicación es una tubería de datos y los efectos quedan en los bordes.
Blinda el Núcleo
Protege el corazón del negocio.
Las dependencias apuntan solo hacia dentro. Entidades y casos de uso nunca conocen el nombre de un framework.
Mantén la Infraestructura Silenciosa
La infraestructura es solo un detalle.
La persistencia se comporta como una colección en memoria. El fallo es explícito; el estado es inmutable por defecto.
Lenguaje Universal y Contratos
Habla el idioma del usuario.
Lenguaje ubicuo explícito en contratos design-first. Los primitivos se envuelven; todo método público tiene contrato.
La métrica principal
La complejidad ciclomática —el conteo de caminos independientes de un método, de Thomas J. McCabe— es el instrumento principal de la filosofía. Un método con complejidad superior a 5 se rechaza, por legible que parezca. Cinco caminos ya son cinco razonamientos que el lector debe sostener a la vez.
Todo lo demás en la sección de disciplina sirve para mantener ese número bajo: un nivel de indentación, sin ELSE, sin switch/case, cláusulas de guarda, extracción. La métrica es medible en todos los lenguajes de este libro, y cada ecosistema tiene una herramienta que la reporta.
Las cuarenta reglas
Cada regla tiene un umbral medible. En caso de duda, elige la opción más restrictiva.
40 reglas · 7 grupos · 5 pilares
OComplejidad
- La complejidad ciclomática por método no puede exceder 5.
- Solo un nivel de indentación por método.
- No use la palabra clave ELSE (cláusulas de guarda o retorno temprano).
- Nunca use switch/case (polimorfismo, expresiones match o strategy).
- Evite números y cadenas mágicas (constantes o enums).
OTamaño
- Máximo de 50 líneas por clase (solo el código dentro del cuerpo de la clase).
- Máximo de 20 líneas por método (solo código ejecutable).
- Máximo de 10 clases por namespace o paquete.
- Ninguna clase con más de dos variables de instancia.
- Los métodos no deben tener más de dos parámetros.
- Los constructores no deben tener más de dos parámetros.
- Las interfaces no deben tener más de dos métodos.
ONomenclatura
- No abrevie; use nombres completos y descriptivos.
- Los métodos booleanos empiezan con is, has, can o should.
- Los nombres de métodos empiezan con un verbo.
- Las constantes van en UPPER_SNAKE_CASE.
- Propiedades y métodos en camelCase.
TModularidad
- Colecciones de primera clase: envuelva arrays en clases dedicadas.
- Un punto por línea; evite el encadenamiento de llamadas.
- Métodos estáticos prohibidos, excepto fábricas y funciones puras.
- Comandos y consultas separados: sin efectos secundarios en métodos que devuelven valor.
- Funciones puras cuando sea posible: misma entrada, misma salida, sin efectos secundarios.
- Sin estado global ni singletons; inyecte dependencias explícitamente.
- Prefiera funciones pequeñas y enfocadas; extraiga cuando un método haga más de una cosa.
AProtección
- Sin getters, setters ni propiedades públicas; use métodos de comportamiento.
- Propiedades privadas por defecto; protected solo para herencia de framework.
- Clases finales por defecto; la extensión ocurre mediante interfaces.
- Herencia prohibida, excepto clases base de framework; prefiera composición.
- Valide todas las entradas en la frontera: constructores y métodos públicos.
- Falle rápido: lance una excepción en cuanto se viole una precondición.
- Nunca mute los parámetros de entrada; trátelos como inmutables.
KEfectos secundarios y fallo
- Prefiera la inmutabilidad: propiedades readonly, devuelva nuevas instancias.
- Los métodos que devuelven colecciones devuelven una colección vacía, nunca null.
- Los métodos que pueden fallar devuelven Result/Either o lanzan excepción; nunca null.
- Explícito sobre implícito: sin dependencias ocultas, métodos mágicos ni conversiones implícitas.
- Nunca filtre detalles de infraestructura (SQL, HTTP, rutas de archivo) al dominio.
UContratos
- Envuelva todos los primitivos y cadenas en objetos de valor.
- Sin tipos genéricos (mixed, array, object), excepto en métodos explícitos de serialización.
- Todo método público se declara en una interfaz.
- Los comentarios explican el porqué y pertenecen a los contratos, no a las implementaciones.
Cómo se sostienen los pilares
La disciplina hace posible la composición: una clase de 300 líneas no se puede reemplazar. La composición hace defendible el núcleo: un monolito no puede esconder sus dependencias. Un núcleo protegido hace que la infraestructura sea realmente opcional. Los contratos son la única razón por la que todo esto se puede verificar desde fuera.
Quita un pilar y los demás se vuelven ceremonia. Mantén los cinco y el sistema se vuelve aburrido, como los puentes.